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Objectives 

The objective of this task was to determine the effect of 
Multi-Flight Computer Operations and Update Blocks on the CPU 
utilization, elapsed times, and execut-^on jitter of the ALT Flight 
Software (FSW) . *i.’hese objectives have been accomplished with 
results presented at the FSW ALT Preliminary Design Review. 


Summary of Findings 

Preliminary analysis indicates a total additional CPU cost of 
about 13% for the Approach and Landing Phase of ALT-10% for Update 
Blocks, 2.5% for GPC synchronization, and approximately 0.5% for 
MTU Redundancy Management. This figure does not include any Up- 
date Blocks for SM; however, the cost of these, if there are any, 
should be small relative to the 10% for GN&C Update Blocks. 

Transport lag increased to an average of 15.9 ms (from 14.3 
ms without these functions) . Maximum transport lag increased to 
18.5 ms (from 16.9). Critical input sampling jitter remained the 
same . 


Detailed Findings 

Update Blocks were added to the GN&C portion of the model as 
follows: 3 Update SVC's were added to the Fast Cycle Executive 

(1 at 25 Hz, 2 at 12.5 Hz) , and 4 Update SVC's were added to the 
Mated/Drop Executive (all at 12.5 Hz) (see Reference 1) . Excluding 
synchronization, the FCOS overhead for these 100 Updates/second 
was 2.5% (fv250ysec each). The application processing within 
these blocks added 7.5% to the CPU utilization. 

GPC Synchronization was performed for the following events: 
Update Blocks, Wait for Event, Satisfaction of an Event Wait (via 
SET or SIGNAL) , Timer Interrupts, and I/O Input Completions for 
all devices except the PCMMU. This resulted in about 400 syn- 
chronizations/second at a total CPU cost of 2.5%. Information on 
when synchronization should be performed was obtained from Refe- 
rence 2. Even if the number of sync points should double, synchroni- 
zation costs would only rise to 5%. 

MTU Redundancy Management costs were estimated to be about 
0.5%. At a 12.5 Hz rate, this is about 400ysec per execution of 
the function. Since 12.5 Hz is the maximum rate at which MTU 
RM will be performed (nominal rate is 2 Hz) the cost per exeuction 
could double and the total cost would not exceed 1% . 


The transport increase of 1.6 ms was caused as follows; 

.62 ms application processing within an Update block 
.25 ms PCOS processing for the Update block 
.42 ms FCOS processing for 7 syncs 
.30 ms misc time due to model variability 

1.59 ms. Total 


Future Analysis 

Future efforts in this area should include the following steps; 

1) Obtain data on the usage of Update blocks by SM. 

2) Improve the model of synchronization by charging a varia- 
ble CPU cost based on the number of times the sync routine must 
loop waiting for other GPC's. Currently only an average time is 

charged. 

3) As the design of MFC progresses, verify the points where 
synchronization must be performed and obtain a better estimate 

of the cost of the MTU RM function. 

4) Add these functions to the baseline FSW model to be used 
in all future analysis. 


References ; 

1. Informal information from W. Madden 

2. Digital Development Memo #865, "Quantitative Analysis of 
GPC Synchronization Methods", from Charles Stark Draper Labs, 
Inc., dated 1/10/75. 
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DOWNLIST DATA STALENESS FEASIBILITY ANALYSIS 


FINAL REPORT 


May 23, 1975 


PURPOSE 


The purpose of this task was to determine the feasibility of 
using the* Flight Software model to generate tables showing the 
staleness of the different downlist data items. This purpose has 
been accomplished. 


SUMMARY OF RESULTS 


The Flight Software model can be used to generate staleness 
infoannation. The attached tables show the staleness distribution 
for six selected downlist data items in two different simulation 
runs. Staleness is relatively constant for those data items whose 
collection rate is an integral multiple of their downlist rate; for 
those data items which are collected and downlisted at non-integral 
rates (e.g. collected at 12.5HZ and downlisted at 5HZ) , however, 
the staleness is quite variable from sample to sample.. More detail 
is given below. 


FINDINGS 


The Flight Software model corresponding to the 2/17/75 
Functional Design Specification was used for this study. The 
six data items used were collected via I/O requests from the Past 
Cycle Executive and downlisted at rates of 12.5, 5, or IHZ (see 
Table 1) . Staleness for each downlist item was computed as the 
time between reading the data at the MDM and placing it in the 
downlist buffer. 

Two simulation runs, each simulating 4 seconds of time, were 
made for the study. In the first run (results shown in Figures 
1, 2 , and 3), the CPU estimates given in the 2/17/75 FDS were 
used, creating an overload condition. However, since the Fast 
Cycle Executive and the Downlist are the two highest priority 
tasks, they were always able to complete processing before their 
next execution was scheduled. A second run, with all CPU esti- 
mates reduced by 50%, was made to investigate the effects of 
timing variations on the results. Results of this run are shown 
in Figures 4 and 5. 

The timeline in Figure 1 shows the approximate times of 
gathering inputs and downlisting data for a 1/2 second period of the 
first run (full CPU estimates). The line above the time bar shows 
the active periods for the Fast Cycle Executive (periods from timer 
interrupts going off until CLOSE is issued) with the approximate 
times for gathering data via the three input requests. The line 
below the bar shows Downlist periods of activity with the approxi- 
mate times of downlisting the various items. (Item D6 not shown 
because not downlisted in this period) . 
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Figures 2 and 3 show the staleness information for the six 
data items in the first run (full CPU estimates) ; Figures 4 and 5 
show the same information for the second run (reduced CPU estimates) . 
Each graph shows staleness of data in milliseconds versus the number 
of samples in that range. Although there are some differences 
between the corresponding downlist items in the two runs, the 
general conclusions given below are valid for each run. 


CONCLUSIONS 

Two factors influence the variability of data staleness in the 
two runs. The first is that the Past Cycle Executive performs much 
more work on odd execution cycles than on even. This causes the 
Downlist process to delay beginning its processing on its odd 
cycles until the Fast Cycle Exec finishes. A data item downlisted 
at a rate of every 1st, 3rd, 5th, . . . execution of the Downlist 
process will thus alternate between rapid downlisting and waiting 
for the Fast Cycle Exec 'o finish. The data item *Pwd Atch Pt Cap', 
(3rd graph in Figure 2) \?h±ch is downlisted every fifth cycle of 
the Downlist process, df^rvionstrates this effect. 

The second factor influencing the variability of staleness, 
which has a much more significant effect, is the condition of 
downlisting at a rate not evenly divisible into the data collection 
rate (e.g. collect data at 12.5HZ and downlist at 5HZ) . This creates 
a very large variability in the amount of staleness. The first and 
third graphs in Figures 3 and 5 demonstrate this effect. 

Current efforts towards reducing the cost of Downlist will, 
if successful, permit a larger skew of the Do’*7nlist Process away 
from the Fast Cycle Executive (perhaps 25 ms) ; this will largely 
alleviate the staleness variability caused by the first factor 
mentioned above. No solution is apparent for the second factor 
mentioned, except for making the collection and downlisting rates 
compatible. 
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Table 1 - Data Items Used for Staleness Computations 


( 

Downlist Item 

Sample Rate, Source 

Downlist Rate 

Execution Cycles When 
Downlisted 

D1 - Gyro Roll Rate 

25HZ, GN&C Input #1 

12.5HZ 

1,3, 5, 7, 9, ... 

D2 - IMU lOR 

12.5HZ, GN&C Input #3 

12.5HZ 

2,4,6,8,10, ... 

D3 - Fwd Atch Pt Cap 

25HZ, GN&C Input #2 

5HZ 

1,6,11,16, ... 

D4 - GN IMU Fail 

12.5HZ, GN&C Input #3 

5HZ 

3,8,13,18, ... 

D5 - LH RHC Roll 

25HZ, GN&C Input #1 

IHZ 

5,30,55, ... 

D6 - IMU Plat Temp 

12.5HZ, GN&C Input #3 

IHZ 

15,40,65, ... 

Ready 














Figure 1 . Downlist Fast Cycle Exec - Periods Of Activity 
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PURPOSE AND SCOPE 


The purpose of this study has been to evaluate the performance 
of the Flight Software ADL2 delivery. The scope of this task was 
limited to ADL2 cyclic functions, including the cyclic processing 
invoked by the IMU specialist function. GN&C was simulated in two 
flight control modes, manual direct and manual CAS. 


OBJECTIVES 

The objective of this study was to answer the following ADL2 
performance questions : 

1) What is the ADL2 CPU load? 

2) Can all processes complete within the required cycle time? 

3) What is transport lag and input sampling variation? 


METHOD 

All cyclic processes for ADL2 were modeled. In addition, the 
IMU Major Cycle Processor, which is a cyclic process invoked by the 
IMU specialist function, was modeled. Table 1 contains a profile 
of the ADL2 processes modeled. Crew inputs and demand response 
specialist functions were not modeled. 

The inputs used in modeling UI and SM are provided in Appendix 
A. As in previous studies, the CPU estimates for Polling, Data 
Acquisition and PM Control include an assumed 15% HAL Overhead? 
the total CPU is moderately sensitive to this figure. Appendix 
B contains a breakdown of processing times for GN&C. Two cases were 
simulated: Case 1 had GN&C in manual CAS mode and Case 2 had GN&C 

in manual direct mode. The average CPU for the worst case processing 
load, cluster positioning, was used for the IMU Major Cycle processor. 
Appendix C contains the GN&C I/O profile modeled. 


FINDINGS 


CPU utilization for the ADL2 baseline case 1 with GN&C in manual 
CAS mode was 80.7% (Refer to Table 2). In a two~second simulation, 
one execution of the lowest priority process, IMU Major Cycle 
Processor, was missed because the elapsed time of its previous 
execution exceeded 320 ms, CPU utilization for the ADL2 baseline 
case 2 with GN&C in manual direct mode was 74.8% (Refer to Table 3) . 
All processes were able to complete within their allotted time. 
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TABLE 2 
CASE 1* 

ADL2 CPU UTILIZATION 


APPL FCOS TOTAL 


iii 




DISPLAY UPDATE 

8.7 

.5 

9.2 

POLLING 

.7 

1.0 

1.7 

DOWNLIST 

11.9 

3.6 

15.5 

UI TOTAL 

21.3 

5.1 

26.4 

m 




DATA ACQUISITION 

3.8 

1.5 

5.3 

PM CONTROL 

L2 


lA 

SM TOTAL 

5.0 

1.7 

6.7 

GN.S.C. 

FAST CYCLE EXEC* 

17.2 

12.9 

30.1 

IMU MINOR CYCLE PROC 

8.4 

1.7 

10.1 

PREFLIGHT EXEC 

2.3 

1,0 

3.4 

IMU MAJOR CYCLE PROC** 

3.2 


3.5 

GN&C TOTAL 

31.1 

15.9 

47.0 

Miac 




TOTAL SYSTEM 

57.4 

2L1 

80.7 


•manual CAS MODE 

••adjusted FOR 1 MISSED EXECUTION 


3 


TABLE 3 
CASE 2* 

adl2 CPU utilization 


AE£L E£fiS TOTAL 

U1 


DISPLAY UPDATE 

8.7 

.5 

9.2 

POLLING 

.7 

1.0 

1.7 

DOWN LI ST 

ILl 

lx£ 


UI TOTAL 

21,3 

5.1 


SM 




DATA ACQUISITION 

3.8 

lA 

5.2 

PM CONTROL 

1.2 

,2 

lA 

SM TOTAL 

5.0 

1.6 

6.6 

mS£. 




FAST CYCLE EXEC* 

11.0 

12.7 

23.7 

I MU MINOR CYCLE PROC 

8.il 

1.7 

10.1 

PREFLIGHT EXEC 

2.3 

1,1 

3.4 

I MU MAJOR CYCLE PROC 

3.6 

.3 

5.9 

GN&C TOTAL 

25.3 

15.8 

41.1 

E1LS£ 




TOTAL SYSTEM 

51.6 


74.8 


*MANUAL DIRECT MODE 
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Transport lag was measured as the time data from Input 1 or 2 
leaves the MDMs to the time Output 1 data arrives at the MDMs. The 
Fast Cycle Executive must perform 4.88 ms of transport lag processing 
in manual CAS mode and 2.3 ms of transport lag processing for manual 
direct mode. Transport lag for manual CAS mode, case 1, ranged from 
10-21 ms and exceeded the required upper bound of 15 ms 22% of the 
time. Since manual direct mode requires 2.5 ms less transport lag 
processing, transport lag results for case 2 were better. The range 
was 7-16.6 ms and 2% of the cases exceeded 15 ms. 

Sampling variations are defined as the variation from 40 ms of 
the difference in the times between succeeding samples of Input 1 
data on the PP MDMs and Input 2 data on the PA MDMs. Sampling 
variation results for Input 1 showed that 78% of the samples 
exceeded ,8 ms in manual CAS mode and 54% of the cases exceeded 
.8 ms in manual direct mode. The requirement is that not more than 
4% can exceed .8 ms. The maximum sampling variation exceeded the 
required 4 ms upper limit in 24% of the samples for manual CAS mode 
and in 8% of the samples for manual direct mode. In manual CAS 
mode the sampling variation was as high as 9.4 ras and in manual 
direct mode it was as high as 6.4 ms. The sampling variation for the 
FA MDM (Input 2) meets requirements for both GN&C modes. 

Factors that contribute to transport lag and sampling jitter 
are discussed in detail in the FSW ALT PDR Analysis Report . An 
additional contributing factor is that the ALT PROM chained input 3 
is broken into 4 separate read requests, inputs 3, 4, 5 and 6, for 
ADL2. Although these requests are issued before the close of the 
Fast Cycle Executive, they are not complete before the start of 
the next minor cycle. Thus, on every even cycle Input 1 is delayed 
because the PF MDM is busy with I/O requests issued on the previous 
odd cycle. Figure 4, a profile of elapsed times for GN&C I/O requests, 
illustrates the contention for the PF MDMs. 

The best way to eliminate this contention is to reduce the 
number of I/O transactions to the FF MDMs on the odd minor cycles. 
Since MSBLS data is not processed for ADL2, both cases were run 
with Input 6 (MSBLS) deleted. Without Input 6, transport lag and 
sample variation requirements were met for the manual direct mode. 

By deleting input 6 and by moving output 3 (DDU) to the even minor 
cycles, transport lag and sample variations were met for manual 
CAS mode. Refer to tables 5 and 6 for a summary of transport lag 
and sample variation results. 


- 5 - 


TABLE 4 


GN&C I/O PROFILE FOR 2 AVERAGE MINOR CYCLES FROM CASE 1* 

5 10 15 20 25 30 35 40 45 50 55 60 65 70 


Input 1 


il 1 

Input 2 


|i 1 

iCZD 


Fast Cycle Exec 
Processing 

Output 1 
Input 3 

I 

I Input 4 
Input 5 
Input 6 
Output 2 
Output 3 




75 


Time In 
80 MS 


wait time 


Application Processing 
*GN&C in m=tnual CAS mode 











BASELINE 


MANUAL DIRECT MQPg 
BASELINE 

MANUAL CAS MODE 

MANUAL DIRECT WITH 
INPUT 6 (mSBLS) DELETED 
MANUAL CAS WITH 
INEUT 6 (mSBLS) DELETED 
MANUAL CAS WITH NO INPUT 
6 AND OUTPUT 3 (dDU) 


M 


lOVED TO EV 





j BASELINE MANUAL DIRECT 

MODE 

r BASELINE MANUAL CAS 

MODE 

; MANUAL DIRECT MODE WITH 
iNP_UT_ 6 (msbls) deleted 

MANUAL CAS MODE WITH 
INPUT 6(msbls) deleted. 


MANUAL CAS WITH NO 
INPUT 6 AND OUTPUT 3 


SAMPLING VARIATION RESULTS 










RESULTS AMD RECOMMENDATIONS 


CPU utilization for cyclic ADL2 processes is 80.7% for manual 
CAS mode and 74.8% for manual direct mode. With 80.7% CPU utiliza- 
tion the lowest priority process was not always able to complete 
within its cycle rate. If more accurate CPU estimates are desired, 
ADL2 CPU utilization should be resized when CPU estimates based on 
ICS processing times are available for Polling, Data Acquisition 
and PM Control, 

If it is determined that CPU for ADL2 should be reduced, one 
way would be to implement the new Downlist design for ADL2. This 
design, consisting of executable tables, would reduce the 15.5% CPU 
cost for Downlist to 5.1%, 

Although transport lag and sample variations requirements are 
not met for the ADL2 baseline, these requirements can be achieved 
by redistributing the 12.5 hz I/O requests for the FF MDM over the 
odd and even minor cycles, as described in Findings . 


REFERENCES 


Flight Software ALT PDR 
3/21/75. 


Analysis Report by K, L. Williams, 
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APPENDIX A 
SM INPUTS FOR ADL2 

• BASED ON ESTIMATED INSTRUCTION COUNTS 2,5u INSTRUCTION PLUS 15 % 
HAL OVERHEAD 

DATA ACQUISITION 

• 1 PMU read/cycle FOR AN AVERAGE OF 39 WORDS 

• 387 16-bit WORDS read per second 

• 66 interapplication words read per second 


PM CONTROL 

NO precondition^ special COMPUTATION OR LIGHT AND ALARM MANAGEMENT 


EDA 

MEASUREMENTS 

SAMPLES 

f SAMPLE RATES 



#• DISCRETE PARENTS 

, 23 

46 


(114 discretes) 


• FAIL RATE 

1 GOING BAD PER FDA CYCLE 
1 GOING GOOD PER FDA CYCLE 


1 
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DOWNLIST INPUTS 




nnwMJ TRT (25 hz) - PROCESSING TIMES BASED ON UAL EXPANSION OF ASSEMBLY 

ft "w ■ i .. O l^y /* I V r%«Ll 


t 

9 

9 

9 


LANGUAGE INSTRUCTIONS X 2. 5y /INSTRUCT I ON 
THE NUMBER OF WORDS DOWNLISTED IS 125^1 16-BIT WORDS PER SEC 
3 RATE GROUPS 1/SEC^ 5/SEC^ 12.5/SEC 
THE NUMBER OF WORDS MOVED PER EXECUTION - 48 
NUMBER OF CONTIGUOUS DATA GROUPS PER EXECUTION “ 40 


1 PCMMU write/cycle OF 128 WORDS; 3 CHAINED REQUESTS PER 
WRITE 


: i 


UI INEUIB 


DISPLAY. 


U PDATE CLhz) “ PROCESSING TIMES BASED ON NUMBER 
ASSEMBLY LANGUAGE INSTRUCTIONS X 


§ 


F CODED 

• bvi/lNSTRUCTION 


• 2 ACTIVE DEU^S 

• DISPLAYS SUPPORTED; 

RM SENSORS AT IhZ 
I MU CONTROL AT IHZ 
SYSTEM SUMMARY AT IhZ 
FCS/DED DISP AT IhZ 

DISPLAY UPDATE CPU COST INCLUDES UPDATING OF THE TWO LARGEST 
DISPLAYS^ SYSTEM SUMMARY AND RM SENSORS. 

SYSTEM SUMMARY CONTAINS; 

34 ANALOGS 


11 SCAURS 
76 REMOTE TEXT 
67 BILEVEL TEST 
35 STATUS BYTE CHECK 
96 Xj Y COORDINATE SETS 
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RM SENSORS CONTAINS'. 

14 SCALARS 
4 REMOTE TEXT 
36 X^ Y COORDINATE SETS 


POLLING C5hz) 


- PROCESSING TIMES BASED ON ESTIMATED INSTRUCTION 
COUNTS X 2. 5v /INSTRUCT I ON PLUS 15% HAL OVERHEAD. 
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APPENDIX B 

FAST CYCLE EXEC. - ADL2 



EXEC. timeCmsecI 

RAIL 

fay 

EXECUTIVE SEQUENCER 

96 

25 

0.240 

FCS DATA PROCESSOR 1 




*RGA PROCESSING 

331 

25 

0.828 

*AA PROCESSING 

220 

25 

0.550 

*ELEVON FEEDBACK PROCESSING 

421 

25 

1.052 

ELEVATOR COMPUTATION 

38 

25 

0.095 

PROCEDURE LOGIC 

40 

25 

0,100 

ELEVATOR MANUAL DIRECT (MD) 




CONTROL ELEMENT** 

356 

25 

0.770 

AILERON MD CONTROL ELEMENT** 

308 

25 

0.770 

RUDDER MD CONTROL ELEMENT** 

268 

25 

0.670 

FCS COMMAND PROCESSOR 




ELEVON & RUDDER CMD. COM- 




PENSATION 

132 

25 

0.330 

SPEEDBRAKE CMD. COMPENSATION 

26 

12.5 

0.033 

PROCEDURE LOGIC 

40 

25 

0.100 

FCS DATA PROCESSOR 2 




25hZ DISCRETES SELECTION 




FILTERING 

315 

25 

0.788 

TRIM PROCESSING 

59 

25 

0.148 

12.5hZ DISCRETES S.F, 

195 

12.5 

0.244 

PITCH & roll/ YAW PBI PRO- 




CESSING 

39 

12.5 

0.049 

*RHC PROCESSING 

860 

12.5 

1.075 

BODY FLAP DISCRETES PRO- 




CESSING 

56 

6.25 

0.035 
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reproducibility op the 

ORIGINAL PAGE IS POOR 

FAST CYCLE EXEC. (MANUAL DIRECT) “ ADL2 (cONT.) 


mui£ 

EXEC. TIME (PSEC) 

RATE 

toi 

*SBTC PROCESSING 

200 

6.25 

0.125 

SPEEDBRAKE TAKEOVER/sTANDBY 

125 

6.25 

0.078 

*rpta processing 

467 

6.25 

0.292 

*SPEEDBRAKE & B.F, FEEDBACK 




processing 

210 

6.25 

0.131 

AILERON POSITION COMPUTATION 

9 

1.04 

0.001 

*RUDDER FEEDBACK PROCESSING 

105 

1.04 

0.011 

PITCH CONTROL ELEMENT 

816 

12.5 

1.020 

roll/ YAW C.E. 

864 

12.5 

1.080 

BODY FLAP C.E. 

304 

6.25 

0.190 

TOTAL 



10.925 


*1 LRU GOES THROUGH SELECTION 

FILTER 



**IN MANUAL CAS (MC) MODE; 




ELEVATOR MC CONTROL ELEMENT 

1557 

25 

3.893 

AILERON MC CONTROL ELEMENT 

635 

25 

1.587 

RUDDER MC CONTROL ELEMENT 

935 

25 

2.338 
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If.- 

1 rfe 

IMU MINOR CYCLE 

PROCESSOR 

- adl2 


li ""module. 1 

•XEC. TIME 

SAI£ 

lC£.U. 

h IMU 

BITE PROCESSING 

600 

25 

1.50 

' } IMU 

ACCELEROMETER PROCESSING* 

576 

25 

1.44 

;] 

j IMU 

RESOLVER PROCESSING* 

1394 

25 

3.48 

J IMU 

GYRO TORQUE PROCESSING* 

584 

25 

1.46 

IMU 

MINOR CYCLE PROCESSING* 

200 

25 

(L5Q 


TOTAL 



8.38% 


*REPRESENTS 1 IMU 


IMU MAJOR CYCLE PROCESSOR G.25hz)-ADL2 


FUNCTION 


-LUSTER POSITIONING 
GROUND SEQUENCE* 


MAX. % CPU AVG C% CPU ) MIN I 

3.98 3.16 2.90 

3.91 1.36 1.36 


^CLUSTER POSITIONING AND GROUND SEQUENCE ARE MUTUALLY EXCLUSIVE EVENTS, 

PREFLIGHT EXECUTIVE “ ADL2 


MODULE 

AIR DATA CONVERSION 
AIR DATA CALCULATIONS 
CALLS TO PROCESSING STUBS 
DISPLAY PROCESSING*- 1 MU CONTROL 
MONITOR DISPLAY 

TOTAL 


RATE. 

12.5 

12.5 

12.5 

12.5 


%CPU 

0.765 

1.071 

.263 

.181 
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APPENDIX C 

ADL GN&C l/o Pr^nPTI F 


uaE Uj-gRou . p 1 saie 

25hz 

ACCELEROMETER ASSEMBLY 
LEFT AND RIGHT RHC 
LEFT AND RIGHT SBTC 
LEFT AND RIGHT RPTA 
FF MDM DISCRETES 

INPUT GROUP 2 25hZ 

RGA 

ASA FEEDBACKS 
FA MDM DISCRETES 
LEFT AND RIGHT AFT ATTACH PT 
VOLTAGES 
APU PRESSURES 

INPUT GROUP 3 12.5hZ 

ADTA 

INPUT GROUP 4 25hz 

IMU 

(time tag) 

INPUT GROUP 5 12.5hz 

tacan 

RA 


MDM 

ff1-4 


faI-^ 


ff1-4 


ff1-3 


ff1”3 


INPUT GROUP 6 
MSBLS 


“ 16 - 


12 , 5hz 


ff1-3 


RATE 


MDM 

OUTPUT GROUP 1 25hZ FF1-4 

ASA COMMANDS 
FA MDM DISCRETES SET 
FA MDM DISCRETES RESET 

OUTPUT GROUP 2 25hz ff1-4 

FF MDM DISCRETES SET 
FF MDM DISCRETES RESET 
SPI 

TACAN CONTROL REG 
I MU TORQUE & SLEW COMMAND 

0_UXPUT GROUP 3 12.5hz ddu1-2 

DEDICATED DISPLAY UNIT 
DEDICATED DISPLAY UNIT #2 



PURPOSE AND SCOPE 


the Pco? evaluate the performance of 

thi SS I/O the lOP SofSSe? under 

Ptofile* The scope was restrictet^ ■fr^ ■t-Vio Trtrs 
the resulting change in the APlOl CPU cost of r/n software; 

not addressed in the model. ^ Management was 


OBJECTIVES 


The objectives of the study were twTFnii^* 4 -v j j 

perfoLanS: oTtha"iop"ili?rrSpa^r?S^^^ 

2) J I' ^ loadxng, and service response times- 

acteristiL ?rcali£atr?he%l-''S?®S^ performance ihar- 

Both Of these objectives have belf aSmpJShid!^^ simulation model, 


SUMMARY OF RESULTS & RE COMMEND AT TOWg 


the <ieIfgfLalyserp??or°to''tL"?^^^ 

i:s^rs-:.:rs“s ~ 


?equestrLls?;if true £ofS“f ti^riTo 


interval between^poin^^wh^e^the^rnp is tbe time 

While more than qr? checks for new work to start; 

wnxxe more than 95% of these intervals were less than 

on these lono Saths at ti should embark 

requirements? staying within 


METHOD 


exe=uSr:hefnt°?/S"?tttts?™aSt/"?ts“""'°""'- 

for new work to perform (as directed by the^CPU? ^and°to°st^°t 
the appropriate routine 9 ) pTnmr’MniT • ^ * and to start 

BCB procrLs tor a 
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is executed to monitor for request completion and interrupt the CPU 
on a completed request. 

These routines were modeled by simulating the MSC instructions 
required to perform the functions of each, together with a control 
structure. to determine which logic paths were to be taken. Statistics 
were obtained on DMA activity and queueing, elapsed time for the 
routines (actually for segments of the MNTR routine) , variability 
in starting a request, and intervals between checking for new work 
to start. Results given below are organized in this fashion. 


findings 


DMA Activity 

There were about 49000 DMA requests per second in the 
modeled run - 29000/sec for the MSC and 20000/sec for the BCE’s. 

This load requires 3.9% of all available memory cycles and causes 
an effective additional CPU utilization due to I/O interference 
of 2.8%. A threshhold of 8 pending DMA requests was used to cause 
the burst mode to be entered. The maximum number of outstanding 
requests observed in the model was 10, and only about .2% of requests 
were issued in the burst mode. Table 1 provides more detail on 
these results. 

MSC Routines Elapsed Time 

As stated previously, three MSC routines, PIOMPSDO, 
FIOMCNTL, and FIOMNTR, were modeled for this study. FIOMPSDO is 
active when no I/O is outstanding. It checks for new work every 
120usec, and branches to the appropriate routine as directed by 
the CPU. The MSC spends about 73% of its time in this routine. 

FIOMCNTL is the routine used to start the BCE programs asso- 
ciated with an I/O request. Its average elapsed time is 172usec, 
with a range of 150-220ysec. The MSC spends about 4% of its time 
here. 


FIOMNTR is the routine that monitors for request completion and 
notifies the CPU when the request is complete. The routine con- 
sists of three segments: 1) the set-up time prior to issuance of 

the RAW instruction; 2) the RAW instruction itself, which actually 
recognizes the request completion; and 3) interrupting the CPU. The 
set-up portion of the routine requires an average of 78)jsec, and 
ranges from 70 to 95ysec. The RAW instruction will wait for com- 
pletion for up to 112ysec before timing out and eventually repeating 
itself; when it finds a completion, then, it takes an average of 
about 56ysec. The clean— up segment of the routine requires an 
average of 58psec, and ranges from 50-65ysec. The Monitor routine 
IS active about 23% of the time. 
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Table 1 - DMA Activity 



Requests/ sec 

Avg response 
(jisecJ including 
queuing 

Maxiimun 

response 

(ysec) 

% 

Queued 

up 

% of time 
Instruction 
was delayed 

Total 

48800 

3 . 2ysec 

1 

19ysec 

34% 


MSC 

29000 

2.5]isec 1 

i 

18ysec 



Head 

28100 

2. Sysec 

18ysec 

... 

15% 

Write 

900 

3 . lysec 

16ysec 

— 

0% 

BCE 

19800 

4 . 3ysec 

19ysec 



Read 

17500 

4.3ysec 

19ysec 

— 

0.5% 

Write 

2300 

4. 4ysec 

ISysec 

- 

0% 













Table 2 

Request Start Variability 


Time (psec) 


0-50 

50-100 

100-150 

150-200 


% of samples in this 
range 


40% 

34 

21 

3 


Cumulative % 


4u 
7 


200-250 


2 



Table 3 


Interval Between Checking for New Work 


Time (ysec) 

% of samples in this 
ranqe 

Cumulative % 

100-120 

78.7% 

78.7% 

120-140 

1.0 

79.7 

140-160 

0.1 

79.8 

160-180 

1.0 

80.8 

180-200 

14.1 

94.9 

200-220 

2.9 

97.8 

220-240 

0.2 

98.0 

240-260 

0.2 

98.2 

260-280 

1.1 

99.3 

280-300 

0.7 

100 


Request Start Variability 

The average time between the CPU requesting new work 
the MSC starting on the work at FIOMCNTL is 73psec. Table 2 gives a 
further breakdown of the distribution of this time. Assuming that 
lOP ' s could differ in starting a request by the maximum variability 
shown for a single lOP, this figure (250ysec) is the major impedi- 
ment to meeting the SOOysec window for redundant sensor reads. 

If this requirement is firm, design changes may be required to 
reduce the start variability. 

Intervals Between Checking for New Work 

As stated earlier, this time is the limiting factor of 
request start jitter. The average time between checking for work 
is 135 sec. Table 3 gives a distribution of the times. The longest 
path without checking in the MSC routines is in FIOMNTR; it occurs 
when all BCE’s for a request finish just before the MSC times out of the 
RAW instruction. This path can take up to 300psec. It should be noted 
that other MSC routines are designed but were not modeled (Self- 
test, Compare word exchange). The execution time of these routines, 
if longer than 300-|Jsec, can increase the maximum interval described 
here . 


REFERENCE 


lOP Software Analysis - Initial Report by R. W. Burns, Jr., 
4/23/7 5 . 
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1 . 0 MANAGEMENT OVERVIEW 


This report covers two major Utility/Data Flow areas; Cl) Test 
Control Supervisor (TCS) ; (2) Frequency Response Tests (PRT) . 
Analysis of the current UDP design shows these findings: 

TCS 


• 5 test sequences can do work simultaneously assuming 
no test sequence is CPU bound. 

• all 5 test sequences will share the CPU equally if the 
test sequences contain I/O reads and testing with 
averaging . 

FRT 


• FRT I does not meet the requirement that all responses 
from avionics stimuli fall within 1 ms. The response 
variation was 7 ms. 

• FRT II cannot complete its workload in the 10 ms allotted. 
The average elapsed time of the task was 12.7 ms. and 

the task missed 50.5% of its scheduled executions in a 
2 second simulation 

Based on the above findings, further analysis was done to 
address solutions for the FRT performance problems. This analysis 
produced the following recommendations that will permit FRT to 
meet response time requirements; 

• Synchronize all cyclic process starts. (Tq) 

• Skew the start of FRT I process 15 milliseconds from Downlist 
by scheduling FRT I 15 milliseconds prior to Tq. 

• Make FRT the highest priority task in the system. 

• Write a hard-coded BCE program which will write to the 
activators and read the sensors. . 

e The lOP Software design in FCOS 5.0 release is needed to 
meet FRT II requirements to cycle every 10 ms. 
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PURPOSE AND SCOPE 


The purpose of this task was to evaluate the performance of the 
UDP software. This evaluation was done in two steps: (1) evaluate 

the efficiency of the Sequence Processor Module while running five 
test sequences simultaneously; and (2) evaluate the response time 
for Frequency Response Tests (FRT) Part I Write Commands to the 
Control Surfaces, and evaluate the I/O loading effects for FRT 
Part II. 


3.0 OBJECTIVES 

The objectives of this task were to help UDF software designers 

to; 

(1) determine the most efficient method to run multiple 
test sequences simultaneously (5 maximum) . 

C2) determine a read/write method for FRT Part I to meet the 
requirement that elapsed times between the write command 
to the control surfaces reading the MDM and the response 
from the read command reaching the MDM will not vary more 
than 1 millisecond. 

(3) determine if FRT Part II meets requirements to write to 

six Control Surfaces and read 28 Control Surface responses 
in 10 milliseconds. 

These objectives were achieved in this task. Another objective, to 
show the impact of Housekeeping Data Acquisition processing, was 
not accomplished and is deferred for future UDF analysis tasks. 


4 . 0 METHODS 


To accomplish these objectives a model of UDF was developed. 

For step 1, the model includes: 

(1) a functional Single Command Processor 

a functional Sequence Acquisition Processor 

a detailed Sequence Processor Module which sequences 
through any test sequence. CPU is charged by operator 
function sc that it varies with each unique test sequence. 


(2) 

( 3 ) 


2 


steps 


In addition to the modules above the model includes for 
and 3: 

(1} a functional FRT Part I Control Module. 

(2) one functional Aerosurface Actuator CASA) program. 

(3) a functional Command module. 

(4) a functional/ Cyclic Waveform Generator module. 

(5) a functional Control Surface Read module. 

Both steps will run in an environment of; 

Cl) LDB polling at 2o Hz. with no data input. 

C2) DEU polling at 5 Hz. with no data input. 

(3) Downlist data at a rate of 3200 16-bit words/second. 

See Figure 1 for the organization of the Flight Software 
model and its interactions with the ODF model. 

Priorities to be used for this study are: 

(UDF priorities are relative) 


1. 

Downlist 

246 

2. 

DEU Polling 

230 

3. 

LDB Polling 

134 

4. 

Single Command Processor 

129 

5. 

Sequence Acquisition Pro- 
cessor 

110 

6. 

Sequence Processors 

69-65 

7. 

Waveform Generator 

60 

8. 

FRT Control 

58 

9. 

FRT Control Surface Read 

58 

10. 

ASA Program 

56 
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11. FRT Command 


52 


12. Telemetry Format Load (TFL) 

Program 44 

13. Computer Status Lights Test 42 

Figure 2 shows the assumptions made for the TCS studv and 
Figure 3 lists the process tiraes assigned to the TCS operators. 
Figure 5 shows the System Software environment used on the FRT 
study. 


5.0 FINDINGS 

5 . 1 TCS 


TCS has no apparent problems with the current design. 
Five sequence processors can get work done simultaneously. 

The test sequences used in this study were not 
typical, rather, an attempt was made to create a 'worst 
case' condition (See Figure 4). The highest priority 
Sequence Processor executed a test containing only 
repeated read with no averaging. This is a minimum of 
I/O activity by the highest priority task, yet, all four 
Sequence Processor, at a lower priority, were able to 
accomplish work (See Figures 8 and 9) . Figure 10 shows 
the ratio of process time to time lost because the CPU 
was not available. (Task suppression time) 

A more typical test sequence would have reads and 
tests with averaging and, possibly, some delays. These 
delay periods would allow all Sequence Processors to 
complete an equal amount of work. 

If any Sequence Processor executes a test sequence 
without any I/O or delays, all Sequence Processors at 
a lower priority will be 'locked out' and unable to 
accomplish any work until the higher priority Processor 
completes. 

5 . 2 FRT 


The large variability of the current lOP design 
(FCOS 4.0) prevents FRT I and FRT II from meeting current 
response requirements. 
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I The two cases run for FRT I are summarized below (see 
Figure 6 for detailed case descriptions) . 

Case I - The current FRT I design and the current 
lOP design were used in this case. 

Case II -> The new lOP design (FCOS 5.0) was used in 
this case. 

Case II indicates that the new lOP design will reduce the 
variability between the write request and the response data 
to 1 ms, which is the requirement (See Figure 11). Since the 
modeled response is bordered on exceeding the requirement, it 
is recommended that a BCE program be written which will issue 
both the write to the actuators and the read of the sensors. 

This hard-coded BCE design modification could not be 
measured in the current lOP model, but, analysis of the FCOS 
capabilities indicates 67 microseconds is the maximum varia- 
bility that will occur between a series of write— read requests. 

^RT II The four cases run for FRT II are summarized below 
(see Figure 7 for detailed case descriptions) : 

Case I - The current FRT Ii design and the current lOP 
design were used in this case. 

Case II - The use of the hard-coded BCE program was 
implemented in this case. 

Case III- The new lOP design was used in this case. 

Case IV - Both the new lOP design and the hard-coded 
BCE program were implemented in this case. 

As the data in Figure 12 indicates, the hard-coded BCE 
program alone is not sufficient to meet FRT II requirements. 

The missed executions were reduced to 25.5% from 50.5% with 
the BCE program. Since the BCE program is required for FRT I 
and it does help FRT II response it should be used for both. 

A savings of 5% FCOS CPU utilization is also realized by using 
the BCE program. The new lOi' design i s needed to meet FRT II 
requirements as Cases III and IV indicate. 
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6.0 RECOMMENDATIONS 

Recommendations 1*"3 are to make the FRT system more efficient 
Recommendations 4-5 are needed to meet FRT requirements. There 
are no recommendations at this time for TCS. 

1. Synchronize all cyclic process starts (T ) . This allows 
control of the system workload and helps predict variations 
xn that workload. 

2. Skew the start of FRT I process 15 ms from Downlist fay 
schedulxng FRT I 15 ms prior to T^. 

3. Make FRT the highest priority tasks in the system, FRT II 

has the fastest cyclic rate in the system and should have 
prxorxty to get its work done. When using the FCOS 5.0 
lOP uses flight critical busses which will 

have the 2nd hxghest I/O priority next to ICC traffic. 

4. Write a hard-coded BCE program which will write to the 
actuators and read the sensors. This ensures a minimum 
variation xn the elapsed time between write and read 
commands for FRT I. 

5. The FCOS 5.0 lOP design must be available to UDF for FRT II 
to meet requirements . 


REFERENCES 
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APPENDIX A 


FSW PERFORMANCE MODEL ORGANIZATION 
FOR UDF STUDY 





-+ 

UDF 

1 ^ 



ROUTINES TO SIMULATE EXTERNAL DPS 
INTERFACES INCLUDING: 

• ROUTINES TO TABULATE STATISTICS 
ON DEVICES TIED TO MDM's AND DBIU 


• FLIGHT COMPUTER 
« lOP 

• ALL DEVICES THAT 
lOP 

t PROCESS MGT, 
f I /O MGT . 


• DISPLAY SUPPORT 
0 DISPLAY FORMAT- 
• TING 

0 LDB POLLING 


INTERFACE WITH 

0 CONFIGURATION 
MGT. 

0 INTERFACES TO 
OTHlR FUNCTIONS 

0 DISPLAY UPDATING 
0 DEU STATUS MAIN- 
TENANCE 


0 TEST CONTROL SUPERVISOR 
0 GENERAL TEST SUPPORT 
0 FREQUENCY RESPONSE TESTS 
0 TELEMETRY FORMAT LOAD 


FIGURE 1 
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APPENDIX B 


TCS ASSUMPTIONS 


• ENVIRONMENT 

• ALL OPERATOR INPUTS PREVIOUSLY RECEIVED 
0 MODS POLLING WITH NO INPUTS 

• DISPLAY UPDATE WITH NO DISPLAYS 

• DOWNLisT 3200 16-bit words/second 

• NO I/O ERRORS 

• TEST SEQUENCES ON MASS MEMORY 

• 5 TEST SEQUENCES RUN CONTINUOUSLY 

• FORCED HEAVY WORKLOAD ON HIGHEST PRIORITY PROCESSOR 

IN ORDER TO ASSESS IMPACT ON LOWER PRIORITY PROCESSORS 


FIGURE 2 
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TCS PROCESS TIMES 


OPERATOR PROCESS TIMES IN yis 


BEGIN 




110 

ISSUE 




1400 

READ 

(no averaging or 

1st read) 


1840 

READ 

(averaging-each 

subsequent 

read) 

600 

TEST 

(no averaging or 

1st read/test) 

2920 

TEST 

(averaging-each 

subsequent 

read/test) 

1680 

DELAY 




300 

BRANCH 



1100 

CALL 




890 

TEXT 




620 

STOP 




1000 

END (main sequence) 



1150 

END (subsequence) 



830 


TASK/EXECUTION 

Sequence Acquisition Processor 2130 

Sequence Processor (plus Operator Charges) 900 


Figure 3 
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TCS TEST SEQUENCES 


• Sequence Processor 1 



Operators 

Processing Time 

1. 

Begin 

llOOys 

2. 

Read 1 word - PP3 

1800ys 

3. 

Repeat steps 1 and 2 

llOOUs 

Sequence Processors 2’-5 



Operators 

Processing Time 

1. 

Begin 

llOOys 

2. 

Text 

620ys 

3. 

Issue 1 word - FFl 

1400US 

4. 

Read 1 word - FFl 

1840ys 

5. 

Test 1 word - PCMMU 

2920ys 

6. 

Issue 1 word - FF2 

1400ys 

7. 

Read 1 word - FF2 

1840ys 


Read 100 samples - wait 

59400ys 


50 ms between samples 


8 . 

Read/Test 1 word - PCMMU 

2920ys 


Test 50 samples - wait 

B2320ys 


100 ms between samples 


9. 

Delay 100 ms. 

300ys 

10. 

Repeat steps 1 through 9 

llOOys 


Figure 4 
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FRT SYSTEMS SOFTWARE ENVIRONMENT 


• DOWNLIST 

• NEW ALT DESIGN 

§ EXECUTE AT 25 HZ RATE 

• OUTPUT 3200 16-bit words/second 

• PRIORITY = 2^6 

• DISPLAY UPDATE 

• NEW ALT LOADING ESTIMATES 

• EXECUTE AT 10 HZ RATE 

• UPDATE 3 DISPLAYS 

• OUTPUT 32 16-bit words/second for 3 deu's 

• PRIORITY = 142 

• MCDS POLLING 

f execute at 5 HZ RATE 

• POLL 3 DEU's 

• NO KEYBOARD INPUTS 

• PRIORITY = 230 

• LDB POLLING 

• EXECUTE AT APPROXIMATELY 25 HZ RATE. EXECUTION VARIES 
WITH SYSTEM LOADING. 

• NO LDB INPUTS 

• NO LDB OUTPUTS 

• PRIORiTY = 134 

FIGURE 5 


FRT I ENVIRONMENT 


• EXECUTE AT 25 HZ RATE 

• 2860ySECONDS PROCESSING EVERY ^lO MILLISECONDS 

• 3520)iseconds processing every 80 milliseconds 

f WRITE 16 WORDS TO FLIGHT AFT MDM 1 USING A BCE CHAIN OF 5 ELEMENTS, 
THIS IS THE HARD-CODED BCE PROGRAM WRITTEN FOR GN&C. 

• READ 56 WORDS FROM FLIGHT AFT MDM 1 USING GNSC PROM 

• WAIT FOR l/o COMPLETE FOR BOTH THE WRITE AND READ REQUESTS 

• RESPONSE TIMES MEASURED FROM THE WRITE COMMAND AT THE MDM TO 
THE READ COMMAND AT THE MDM. 

• PRIORITY = 58 

• WAVEFORM GENERATOR/ PRIORITY = 60 

• CASES 

• CASE I 

• WAIT FOR I/O COMPLETE ON READ AND WRITE REQUESTS 

• NO SKEW IN SCHEDULING FRT I 

• PRIORITY = 58 
9 CASE 1 1 

■ CURRENT FRT I DESIGN 

• NEW lOP DESIGN 

• PRIORITY = 249 

• SKEW FRT I SCHEDULE 15 MS FROM DOWNLIST 


FIGURE 6 
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FRT II ENVIRONMENT 

• EXECUTE AT 100 HZ RATE 

• ^40ySECONDS PROCESSING EVERY 10 MILLISECONDS 
® 590uStCONDS PROCESSING EVERY ^0 MILLISECONDS 

• 880y SECONDS PROCESSING EVERY SECOND 

• WRITE AND READ DEFINITIONS ARE THE SAME AS FRT I 
f PRIORITY = 57 

f WAVEFORM GENERATOR^ PRIORITY = 60 

• CASES 

• CASE 1 

• WAIT FOR l/o COMPLETE ON READ AND WRITE REQUESTS, 
f NO SKEW IN SCHEDULING FRT II 
II PRIORITY = 57 

9 CASE II 

e SKEW FRT II SCHEDULE 15 MS FROM DOWNLIST 
9 PRIORITY = 248 

• HARD-CODED BCE PROGRAM 

• CURRENT lOP DESIGN 

• CASE 1 1 1 

9 SKEW FRT II SCHEDULE 15 MS FROM DOWNLIST 
9 PRIORITY = 248 

• CURRENT FRT II DESIGN 

• NEW lOP DESIGN 

• CASE IV 

9 SKEW FRT II SCHEDULE 15 MS FROM DOWNLIST 
9 PRIORITY = 248 

• HARD-CODED BCE PROGRAM 

• NEW I OP DESIGN 

FIGUBE 7 
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DOWNLIST 
MCDS POLLING 
LDB POLLING 
DISPLAY UPDATE 
SEQUENCE ACQUISITION 
SEQUENCE PROCESSORS 
TASK #1 
TASK #2 
TASK #3 
TASK 
TASK #5 


TCS CPU UTILIZATION C%) 

12.87 

1.04 

.36 

.06 

.03 


32.5 

1.3 


1.3 


1.2 


1.1 


FCOS 

TOTAL 


2!L1 

76.1 


FIGURE 8 
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FLIGHT COMPUTER TASK SUMMARY FOR TCS STUDY 


PROCESS 

SUB 

SYSTEM 

RATE 

PRIORITY 

CPU 

MSEC/SEC 

10 REQ 
PER SEC 

DOWNLIST 

UI 

25 hz 

246 

128.7 

25 

MCDS POLLING 

UI 

5 hz 

230 

10.4 

15 

DISPLAY 

UPDATE 

UI 

10 hz 

142 

.06 

12 

LDB POLLING 

UI 

28.5 hz 

134 

3.6 

28.5 

SEQUENCE 

PROCESSORS 






TASK #1 

UDF 


69 

325 

106.8 

TASK #2 

UDF 


68 

13 

13.5 

TASK #3 

UDF 


67 

13 

. 

r-t 

TASK #4 

UDF 


66 

12 

13.4 

TASK #5 

UDF 


65 

11 

13.4 




FIGURE 9 
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TCS TASK PROCESSING AND WAIT TIME 


WAIT FOR CPU USING CPU 


TASK #1 

19.5% 

32.5% 

TASK #2 

9.5% 

1.3% 

TASK #3 

10.7% 

1.3% 

TASK #4 

11.6% 

1.2% 

TASK #5 

16.4% 

1.1% 


TCS I/O RESPONSE TIME 


DEVICE 

# REQUESTS (20 SEC RUN) 

AVERAGE 
l/o RESPONSE 

RANGE 

PCMMUl 

616 

8.76ms 

3ms-13ms 

mdmffI 

10 

4 . 66ms 

3ms-7ms 

mdmff2 

418 

4.61ms 

2ms-10ms 

mdmff3 

2010 

4.29ms 

2ms-8ms 


FIGURE 10 



FRT I RESULTS 


CPU SUMMARY 


TASK 
DOWN LI ST 
MCDS POLLING 
DISPLAY UPDATE 
LDB POLLING 
FRT I 

APPLICATION TOTAL 


2.83 

1.04 

1.52 

.36 

7.97 

13.72 


CASE 

I 

II 

APPLICATION TOTAL % 

13.72 

13.72 

FCOS % 

2£L2a_ 

IZ^ 

FRT TOTAL t 

34.01 

31.01 

RESPONSE VARIATION 

7 MS 

1 MS 


FIGURE 11 
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FRT II RESULTS 



CPU 

SUMMARY 

lASK 


-CM. 

DOWNLIST 


2.83 

MODS POLLING 


i,m 

DISPLAY UPDATE 
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MANAGEMENT OVERVIEW 

In order to evaluate the MFC software design/ modeling analysis 
was performed. The FSW ALT Approach and Landing (A/L) Baseline 
case, as defined in the methods section of this report, showed 
the following: 

9 Total CPU utilization was 114.9% 
e FCOS utilization was 30.2% 

• The number of sync points was 638.5/sec 

9 The lOP software design changes resulted / '■educe 1 I/O 
response time and a decrease in the variability of P 5. .larting 

work on requests. 

» Transport lag averaged 11 ms and ranged between 10.8-11.8 ms. 

• Flight critical input sampling jitter requirements were met. 

• The 30011 maximum input skew requirement may not be met. 

• Bus contention problems did occur but should be solvable 

by optimizing skew of process starts and by balancing the I/O load. 

This report presents MFC Software performance results. Since 
alternate designs were not evaluated, no specific recommendations 
resulted from the analysis task. 


PURPOSE AND SCOPE 


The purpose of this analysis task was to predict the perfor- 
mance of the Flight Software ALT Multi-Flight Computer Software 
functional design as defined in the Space Shuttle <.i r biter Avionics 
Software ALT Functional Design Specification (FDS ) of 7/25/75. 
Performance results, based on model simulations, were presented 
at the Flight Software ALT Delta Preliminary Design Review. The 
scope of the task was limited to ALT Approach and l.uiding (A/Jd 
mode with emphasis on the MFC software in a steady state, error 
free environment. 

OBJECTIVES 

The overall objt'ctive was to evaluate the cd fects of tnc> MFC 
functions on system performance. Specific oijjectives accomplished 
were : 

1) To predict C'PU uti I i/,^^t i on for Ocicli < the.so fimctiens. 
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2) Predict the number of sync points utilized in tne current 
FSW design. 

3) To determine if the skew between the process starts of SIP 
and Fast Cycle Executive enables each of them to complete 
succersfully without interference from the other. 

4) To predict the sampling jitter for the MTU 

5) To predict I/O response times 

6) To predict the occurrence of missed process executions 

7) To determine the effects of increased ICC traffic on the 
successful execution of SIP 

8) To determine the effect of the new lOP software design and 
of the MFC functions on the sampling jitter of critical 
GN&C inputs and on the GN&C transport lag. 

9) To determine if maximum input skew requirements are met. 


METHOD 


To determine the effects of the MFC software, three redundant 
computers were simulated. No drift between the computers' GPC 
clocks was represented. Any drift between the computers due to 
their clock differences must be factored into the cost of syn- 
chronization. 

The model used for this analysis task reflects the rates and 
execution times resulting from the May Scrub and the FSSR rewrite 
for UI, SM and GN&C. This set of rates and execution times is 
referred to as the 'Tornado Baseline' . While the 'Tornado 
Baseline’ does not include all the latest scrub items, it was 
determined to be a good reference point for evaluation of the MFC 
software. Therefore, emphasis is placed on the additional CPU 
loading resulting from the MFC software rather than total system 
CPU utilization. Refer to Appendix A for a list of scrub items 
not included. 


The FKW motlel was updated to reflect the system software design 
as di finod in the of .July 25, 1975. To be specific, updates lot 

the synchronization routines, sync points in FCOS routines, lOP soft- 
ware, Time Management routines. System Interface Processor (SIP), 
usage of Update Blocks/Exclusive Procedures, and ICC interface were 
addf'd to 1 ' FSW model. However, the Downli.st function dc'"= not 

reflect the FDS design. It is modeled to represent the Uownlisu 
design in the 'Tornado Baseline' which will be implemented for ALT. 


- 2 - 


Appendix B contains a summary of the rates and usage of FCOS 
services for the processes modeled. It also shows a timeline 
of the process starts. All processes except the Fast Cycle Exe- 
cutive (F/C Exec.) were scheduled to start at the same time as SIP. 
Thus, multiple processes were started by one timer interrupt re- 
sulting in a CPU savings of interrupt handling overhead. The 
start of F/C Exec was skewed from the start of SIP by 20 ms in 
order to minimize CPU and I/O contention between the two high priority 
processes. Assumptions for modeling the SIP process are also 
documented in Appendix B. 

The operation of the lOP is represented as a series of delays 
in the model. The delay times were derived from the detailed lOP 
modeling study (reference 2) performed on the lOP software defined 
in the FDS of 7/25/75. Appendix C contains a breakdown of the 
lOP delays used for this study. 

Performance results for the Baseline represent nominal condi- 
tions for only cyclic functions in an error-free environment. Non- 
cyclic functions such as specialist functions, crew inputs or 
requests for display changes, and error conditions are not included. 
However, a preliminary evaluation of the effects of transferring 
a full Inter -computer channel (ICC) buffer due to error conditions 
wa s made . 


FINDINGS 

CPU Utilization 


The total CPU utilization for the A/L Baseline case was 114.9%. 
FCOS utilization was 30.2%. Table 1 compares the Delta PDR base- 
line CPU utilization with the CPU utilization for the 'Tornado 
Baseline' (104,1%). The CPU for applications increased 1.3% due 
to SIP processing, FCOS CPU increased due to the following: 

• Additional FCOS required for SIP functions (4.5%) 

• Baseline model results for the cost of MFC software (9.6%) 
replaced preliminary estimates of MFC functions in the 'Tornado 
Base line' . 

As a result of the detailed lOP analysis, references 2, the DMA 
utilization was shown to be 2.8%. 
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Table 2 shows a breakdown by process of application and FCOS 
CPU utilization for the baseline case. The cost of Downlist which 
is called by the SIP process is broken out separately. Table 3 
shows a further breakdown of FCOS utilization. 

Computer Synchronization 

GPC synchronization is designed to keep GPC's together with 
respect to time» data gathering, and internal queue manipulation. 
Based on usage of FCOS services in the Baseline case, 638.5 
synchronization points occurred each second. Table 4 shows a 
detailed breakdown of usage of synchronization routines. It also 
compares the 638.5 sync points per second to the 390.5 sync points 
per second estimated at PDR in March, 1975. The most significant 
difference is that sync was not performed at I/O initiation in the 
preliminary analysis for PDR. 

In order to minimize the number of sync points, the following 
design features were included in the Baseline: 

• No SVC synchronization was performed on change of I/O 
completion event states. Sync was accomplished by the I/O 
completion sync routine. 

• No SVC synchronization was performed on initiation of the 
MTU request which was issued by the SIP synchronization 
routine . 

• Only one sync was required to activate multiple processes 
which shared one timer expiration. 

The cost of sync for the baseline case was 7.6%. This cost 
depends not only on the number of sync points but on the skew be- 
tween computers arriving at the sync points. Each computer must 
execute a non— agree loop until all redundant computers agree with 
its sync code. Each time thru the no-agree loop extends the cost 
of sync by 40ys. Table 5 shows the modeled usage of the no-agree 
loop. Any additional skew between the computers such as GPC clock 
drift or variability in redundant lOPs must be factored in. 

Contention Between F/C Exec and SIP 

As a result of the 20 ms. skew between the process st.jrl;. o: 

F/C Excc and SIP, (See Appendix B) contention for the CPU between 
tht'si' two high prit;rity processes was minimal. SIP ' s average elapsed 
time was 'i . 3 ms . Thus, it is completed 15 ms before the start of 
F/C Kxf'c, wi’ont’’ avoraqo ela|3sed time was 20.3 ms. A 20 ms skew of 
the i>i oci't.;-. starts may not be optimum for load balancing. Further 
analysj: must be made to determine the skew that has the best effect 

on total system performance. 
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Contention for the FF buse* between SIP and F/C Exec occurs 
when the MTU is read by SIP on the same cycle F/C Exec issues its 
12.5 hz I/O requests. Figure 1, which contains a sample timeline 
of the I/O elapsed times, illustrates that the elapsed time for 
I/O requests for the FF buses extended past the start of SIP, where 
the MTU read is issued. Since F/C Exec I/O extends into the start 
of SIP on alternate F/C Exec cycles, bus contention can be 
avoided if the MTU is always read on the cycle that doesn't issue 
the F/C Exec 12.5 hz I/O requests. 

MTU Sampling Jitter 

MTU sampling jitter is the variation in the time measured 
from time tagging the MTU request by FCOS until the MTU data is 
read from the MDM. Due to the impact of bus contention on MTU 
sampling jitter, two cases were modeled. In the case where bus 
contention between F/C Exec was eliminated so that the FF bus was 
always free, the maximum variation to occur was 320ys. In the case 
where contention was not avoided, the variability ranged as high as 
4.6 ms. These sampling jitter results were provided as inputs to 
an indepth analysis on timekeeping by the Mission Studies and Ana- 
lysis Department. Reference 3 discusses the results from this 
analysis, 

I/O Response Times 

Figure 1 contains a sample timeline of I/O elapsed times, 
illustrating the I/O activity for a particular 80 ms period for 
the model simulation. It shows when each request was issued and 
the elapsed time for each request, which includes FCOS, lOP 
processing and data transfer time. 

Missed Process Executions 


Due to overloaded CPU utilization, (114.9%) lower priority 
processes were not always able to complete within their allotted 
time. Missed process executions occur when an interval timer 
interrupt occurs to start the next process' execution and the 
process is still working on the pr^-vious cycle execution. In a 
two-second mode], simulation the following process executions were 
missed : 

1 of '4 Display Update Executions 
11 of 25 Mated/Drop Executive Executions 
1 of 2 PM Control Executions 


If processes continue to miss executions ^fter the CPU uti- 
lization is within requirements,, better balancing of the CPU load 
must be obtained. 


Increased ICC Traffic 

The following two cases were run to determine the effects on 
SIP of increased ICC traffic: 

1) The baseline case with nn I/O oi ror requit i nq input 
Problem Reporting (Tl’R) via K'C. 


2 ) 


The basol i no casr' wi I h nu annun* 
mission (jT Tull !CC bn i fer. 


t |. !• I m i t i ll'l t I i:>s 


tn c-nse 1, "’P ioi nn I ,/n tu roi oir ntn 

FA MOM tied up tho H’C! bn ft; :>irco 

offset, from l’/<’ Kxoo'.n in|.ul. roqiu'r.t , ! h i n 
sip's cyclic r<'qut'sl bn- !li^- t<’( l)us<'s- tii 
a full iCC buM-'i (12B lu-bil. w<Jtd'0 b; :‘b 
elapsed time lot llv- K'>’ ■•>;oh.nKU irom 
the average elapitetd tinnt ol I '.o ;;i!- ittn-e. s;; 
ms to 0.4 ms. llowtrvor, l.he incrt.uisc in tit*- 
no ill effects on sysLom p> >r i’ormnnec' . 


• ’ . . i I I I 1 . 1 I I I '<ui <.d I h 

I Xi ■■ 'I I 1 I ;)1 of SIP i tt 

I I'l^ did no ! (..•ontend with 
1 •, I • , I I . Ill Slit i s: i on o I 
I iMidi-d Uti‘ avor .M)!.' 
i„ ■ t ■ t n . ms . I u I nrn , 

i !i, ■ I < ■■ i.s< :d r r I )Hi b . ' 

n’i‘ d.iLa t ransfer had 


While no ICC contention 
possible contention problems 
continue to be monitored. 


problems existed in tliese two cases, 
could occur. The use of the ICC must 


GN&C Input Sampling Jitter 


Sample variations are defined as the variation from 40 ms of the 
differences in the times between succeeding sailed es of the tim 
critical inputs 1 and 2 of the F/C Exec. The requirement is that 
the variation cannot exceed 2% of the iteration rate of 40 ms, 
i e .8 ms, for more than 4% of the variations and that the 
variation must never exceed 4 ms. Table 6 shows that 
ling litter for the baseline case meets requirements. Ilu' maximum 
sample variation was 1 ms and 25 of tho oaso.s lor m,.ut I oxcoodod 

. 8 mfj . 


The now TOP software design reduced Lhi' variabiliis in 
i;, starting work on . CLiuest (refeii-.iicc 2) . .laU- / -o 
input sampling variation due to the lOP is between 0 2..U;is. 
contributors to sample variation are: 


til.' TOP 

. t . i 

Oi her 
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• Suppression of the start of the F/C Exec due to disabled 
FCOS processing for lower priority processes. 

• I/O interrupts occurring at the start of the Fast Cycle 
Executive which delay the initiation of the critical input requests. 

Transport Lag 

The GN&C transport lag in this study is defined as the elapsed 
time from activation of the FF MDM to read the Accelerometer 
Assembly (AA) to activation of the FA MDM for the critical output 
to the Aerosurface Amplifier (ASA) . The current requirement is 
that the transport lag must not exceed 15 ms. 

In the Baseline case, transport lag requirements were met. 
Transport lag averaged 11 ms and ranged from 10.8 to 11.8 ms. 

Figure 2 illustrates a timeline for an average transport lag. The 
new lOP software design reduced the lOP response time for fight 
critical buses enabling transport lag requirements to be met. 

Maximum Input Skew 

The variation in sampling MDM's commanded by different com- 
puters in a redundant request must not exceed 300ys. Two contri- 
butors to this input skew are: 

• The skew between computers in notifying the lOP of a new 
request. This is equal to the skew between computers 
in exiting the sync routine, or about 50ys. 

• The interval between points where the lOP checks from new 

work, which is defined in Table 8. The maximum interval 
is 300ps. 


While the 300ys input skew requirement will be met in the majority 
of cases, the jitter between lOPs starting a request could be as 
high as ISOys (reference 2) . 


FUTURE CONSIDERATIONS 


Systems Analysis will continue to upgrade the FSW model in 
preparation for the FSW CDR. Model changes anticipated include: 

• Recalibration of CPU sizing data for GN&C, SM, and Systems 
Services. 

• Changes to FCOS as a result of the I CCjS Audit. 

• The GN&C redesign. 

• Usage of the Hybrid Dispatcher 


• Usage of the % SVC macro to replace most of GN&C's Update/ 
Blocks. 

• A new consolidated GN&C I/O Profile. 

REFERENCE S 
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TABLE 1 

COMPARISON OF CPU (%) FOR 
TORNADO BASELINE AND DELTA PDR BASELINE 






APPLICATIM 






GN&C 

GN&C-MOVEMENT OF DATA 
IN UPDATE BLOCKS 
SM , 

ui (polling^ downlist^ 

DISPLAY update) 
UI-SSIP 

52.9 

7.5 

6.2 

14.2 


52.9 

7.4 

6.2 

14.1 

1.3 



total appl 


80.8 



81.9 

FCQS 






SINGLE STRING 
SSIP (minus CYCLING 
AND DOWN LI ST WRITES) 

17.8 

17.8 

16.1 

JL 5 . 



MFC 






UPDATE BLOCKS 
SSIP-UPDATE BLOCKS 

2.5 


1.1 

i D 




2.5 


1.4 



MTU RM 
SSIP-MTU RM 

.5 






.5 


.4 



SYNC 

SSIP-SYNC 

2.5 


6.3 

JLl 




2.5 


7.6 



FDI 

SSIP-FDI 

1 


__I2 




- 


.2 



TOTAL FCOS-MFC 


5.5 


9.6 


TOTAL FCOS 


23.3 




DMA 


II — 



JL3. 

TOTAL SYSTEM 


10^ 



114^ 
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TABLE 3 

FCOS CPU UTILIZATION (%) 
for alt a/l mode 



PROCESS CQNTROI 
DISPATCHER 
SWITCH 
SVC 
CLOSE 

UPDATE block/ EXCLUSIVE PROCEDURE 

TIME MANAGEMENT 

TIMER QUEUE/dEQUEUE 

TIMER QUEUE ELEMENT EXPIRATION 

MTU REDUNDANCY MANAGEMENT 

EVENT MANAGEMENT 
EVENT ST/'TES CHANGE 
EVENT queue/dequeue 
EVENT EVALUATOR 

l/O MANAGEMENT 

£Pi:_ REDUNDANCY MA NAGEMENT 
SYNCHRONIZATION 
FAULT DETECTION ISOLATION 

TOTAL 


- 4.2 

.^1 

2.^1 

lA 

8.8 

1.7 

2.3 

_A 

.8 

.6 

-A 

2.0 

7.2 

7.6 
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BREAKDOWN OF UTILIZATION OF SYNCHRONIZATION ROUTINES 

FOR ALT A/L MODE 


PROCESS 

# 0? 

TIMER SYNC/ 
SEC 

# OF 

SSIP SYNC/ 
SEC 

# I/O 

COMPLETION 

SYNC/SEC 



RHI 

WAIT 

UPDATE BLOCK/ 

EXCLUSIVE 

PROC 

SSIP (Downlist) 

(25) 

25 (0) 

55 (0) 

50 (0) 

■■■■ 

30 (0) 

25 (0) 

Fast Cycle Exec. 

25 (25) 


112.5 (112.5) 

112.5 (0) 

(14) 

25 (25) 

50 (50) 

Data Acquisition 

(10) 


5 (0) 

5 (0) 

HHH 



MCDS Input 
(Polling) 

(5) 


15 (15) 

15 (0) 


- 

15 (0) 

Mated/Drop 

Exec 

(12.5) 





- • ^ 

12.5(12.5) 

50 (50) 

Display Update 

(10) 


4 (12) 

4 (0) 




GPC Switch Mon. 



- 





PM Control 

(2) 


(6) 


1 (0) 

1 (2) 


Total 

25 (89.5) 

25 (0) 

191.5 (145.5) 

186.5 (0) 

2 (16) 

68.5(39.5) 

140 (100) 


I 

> 

CO 

0 Numbers enclosed in parenthesis represent number of syncs represented in preliminary analysis m 
at PDR. 
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TABLE 5 

MODELED USAGE OF SYNC ROUTINES 


NUMBER OF TIMER SYNC POINTS 25/SEC 

NUMBER OF TIMES THRU NO-AGREE LOOP 0 

NUMBER OF SSIP SYNC POINTS 25/SEC 

NUMBER OF TIMES THRU NO-AGREE LOOP 0 

NUMBER OF l/o INTERRUPT SYNC POINTS 191/sEC 

NUMBER OF TIMES THRU NO-AGREE LOOP 141/SEC 

NUMBER OF TIMES INTERRUPTED BY TIMER 

INTERRUPT 0 

NUMBER OF SVC INTERRUPT SYNC POINTS 397/sEC 

NUMBER OF TIMES THRU NO-AGREE LOOP 85/sEC 

NUMBER OF TIMES INTERRUPTED BY l/o 

INTERRUPT 3/sEC 

NUMBER OF TIMES INTERRUPTED BY TIMER 

INTERRUPT 0 
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Flight Critical Input Sample Variation for ALT A/L 
•20 ms Skew between SSIP and Fast Cycle Exec 


Time C sec ) % of samples in this range Cumulative % 

Input I'^FF Input 2 -FA Input 1’>-Fr 

0-200 78 84 78 

200-400 16 10 94 

400-600 2 2 96 

600-800 4 2 100 


j 

i 


800-1000 


2 








TABLE 1 


I/O Request lOP Start Variability * 


Time Cysec) 

% of samples in this 
range 

Cumulative % 

0-50 

40% 

40% 

50-100 

34 

74 

100-150 

21 

95 

150-200 

3 

98 

200-250 

3 

100 


*The variability in the elapsed time between the CPU requesting new 
work and the MSC starting work on the request is represented. 
Distribution resulted from FSW model simulations. 
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TABLE 8 


MSC Interval Between Checking for New Work* 


Time tii sec i 

% of samples in this 
range 

C\imulative % 

100-120 

78.7% 

78.7% 

120-140 

1.0 

79.7 

1 

140-160 

0.1 

79.8 

160-180 

1.0 

i 

80.8 

180-200 

14.1 

94.9 

200-220 

2.9 

97.8 

220-240 

0.2 

98.0 

240-260 

0.2 

98.2 

260-280 

1.1 

99.3 

280-300 

0.7 

100 


♦Elapsed time in MSC software between issuing SEC instructions, 
which causes MSC to look for a new request. 





{ 2 0ms Skew 

Between Fast 

Cycle Exec and SSIP) 

f' . - 

0ms 

10ms 

2 0ms ( 

Jms 40ms 50ms 60ms 

Input 1-FF 

□ 





□ 1 


Input 2-FA 






'□ 1 


Output 1 -FA 

1 

( 

t 

□ 



1 

1 

cz 

j 

Input 3-FF 

1 







Output 2-FF 

1 

1 




1 

c 

1 

] 

Output 3-DDU 

( 

1 

[ 



1 

1 


TsiP MTU Read - 


1 

11 


j 


FF 




( 

1 



801 


SSrP ICC Read 


Downlist 

Write 



Data Acq. 
PMU Read 


Polling I 

Wait time for J 

busses to be free 

Fa Ft Cycle 
Exec Start 


SSIP Start 


Fast Cycle 

Exec Start SSIP Start 










ni.: 


FIGURE 1 







FACTORS CONTRIBUTING TO TRANSPORT LAG 
Average Transport Lag of 11 ms (Range 10.8-11.8 ms I 


Time in ms. 0 1 


2 3 4 5 6 7 


8 


10 11 12 13 14 15 


FCOS 


In # 1 
Ccnip 


Fast Cycle Exec 


DC 


n 


In 2 Comp/ 

Wait on In 1/ 

Update Block 
(. 9ms) 

6.45m s processing 


Avg. Disabled! — TOut 3 Start 


FCOS Pro- 
cessing* 


LJ 


( . 4ms) 


Input 1 
(MSC/BCE) 


Input 2 
(MSC/BCE) 


Avg 1 . 9ms 


Data leaves I 
MDM j 

Avg 1.9ms 

.[ — 

Data leaves MDM 


~n 

I — t 

cn 

c 

33 

m 

ho 


Avg . 7ms 

Output 1 

(MSC/BCE) 

ASA Data Arrives 
at MDM 

*Disabled FCOS processing extending Transport lag includes 
' * Interval Timer interrupts to start lower priority processes 

H • I/O completion Interrupts for lower priority processes 
I • Suppression of Critical I/O Interrupts due to servicina 
lower priority processes. 
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APPENDIX A 


APPROVED SCRUB ITEMS NOT INCLUDED IN BASELINE 

« NZ GUIDANCE 
0 ELIM. OF FADERS 

• COMFAULT PROC 

• RAW DATA SELECT 

• F.O.H. FOR DD REDUCED 

• EVENT LIGHT PROC. 

§ ADI ERROR NEEDLE PROC, 

9 CRT DIGITAL DATA 5) VARIABLE RATE (APPLICATIONS) 

• MICROCODE 

• HAL OPTIMIZATION 

9 LIBRARY OPTIMIZATION 

• HYBRID DISPATCHER 
9 DDU LOADSHARE 
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FLIGHT COMPUTER TASK SUMMARY 
FOR ALT APPROACH AND LANDING MODE 


j PROCESS 

SUBSYSTEM 

RATE 

PRIORITY 

UPDATE 

BLOCKS/ 

EXCLUSIVE 

PROCEDURE 

I/O REQ 
PER SEC 

# WAITS/ 
SEC 

# IMPLIED 
W’A ITS/SEC 

wmi 

MTU 

RM/SEC 

SSIP 

UI 

25hz 

251 

25 

55 

30 


30 

5 

Fast Cycle Exec. 

GN&C 

25hz 

250 

50 

112.5 

25 

37.5 

37.5 

12.5 

Data Acquisition 

SM 

Shz 

234 


5 


5 

1 


MCDS Input 
Polling 

UI 

5hz 

230 

15 

15 


15 



Mated/Drop Exec. 

GN&C 

12.5hz 

150 

50 


12.5 




Display Update 

UI 

2hz 

142 


4 





GPC Switch Mon. 

UI 

Ihz 

134 







PM Control 

SM 

Ihz 

122 



1 


1 


Total 




140 

191.5 

68.5 

61.5 

69.5 

17.5 


I 

NJ 

O 

I 


m m SENSORS 
UPDATE 1/SrC 


ALT DISPLAY SUMMARY FOR APPROACH/LANDING 
•SYSTEM SUMMARY 


UPDATE 1/SEC 


C 






*• -o 

4 — ^ 


• FINAL APyKUACH 
UPDATE 2 /SEC 
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TIMELINE OF PROCESS STARTS 70R ALT './I SASSIINE 


Fast/Cycle 

(F/C) 

Exec 

1 1 1 

F/C 

Exec 

I 

F/C 

Exec 

1 1 

F/C 

Exec 

1 

F C 

F/C 

Exec 

i i 

F/C 

Exec 

1 1 

j j j 

0 20 40 

SSIP SSIP 

•Downlist 
Data Acq. 

MCDS I. -^Ut 

1 

60 

J 1 

80 100 

SSIP 
Mated/ 
Drop 
Exec 

i 1 

120 140 

SSIP 

■ f' r, ■ 0 

Ms "C s ci 
Drcu- 
— 

1 1 

200 220 

SSI? 

D a ~ a Ac q . 
MCDS Input 

I 1 

240 260 

SSIP 

Mated/ 

Drop 

Exec 


Mate-i/Orop Exec. 
Display Update 
GPC Switch Monitor 
PM Control 


I 

w 

h-* 

I 


280 

SSII 


I 

1 

i 

i 

t 

i 








SIP PROCESS PROFILE* FOR CYCLIC FUIMCHONS 


1) SSIP SYNCHRONIZATION IS INVOKED AT TIMER EXPIRATION. 

MTU READ ISSUED 5/SEC BY SSIP SYNC. ROUTINE. 

2) INVOKE ICC MSG COLLECTOR TO TURN ICC BUFFER OFF. (EXCLUSIVE 
PROCEDURE AND 5Qy PROCESSING). 

3) CALL FAULT MESSAGE SCAN 

5Qy PROCESSING AT 25/SEC TO CHECK FLAGS. 

^OOp PROCESSING AT 1/SEC TO SCAN FMPTS. 

4) WAIT FOR COMPLETE OF MTU READ 5/SEC. MOVE INTO ICC BUFFER (50p). 

5) ISSUE ICC WRITE FOR*. 

RM COMPARE WORD - 4 16-BIT WORDS 
GPC TIME - 4 16-bit WORDS 5/SEC 

GPC AND DPS STATUS WORDS - 56 16-BIT WORDS l/SEC 
FDI IS PERFORMED AT ICC l/o COMPLETION. (90p) 

6) CALL DOWNLIST FOR PMU WRITES. 

7) WAIT FOR ICC READ COMPLETE. 

8) CALL ICC ROUTER FOR! 

NO MESSAGE (5Qp) 20/SEC 

MTU DATA MOVED (180)0 5/SEC 

GPC AND DPS STATUS WORDS MOVED (470)0 1/sEC 
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9) light and alarm processing performed on fuel gauging 1/sec. 

10) PROCESS MTU RM 5/SEC 

11) CLOSE 


*370^ OF MISCELLANEOUS PROCESSING IS REQUIRED FOR STEPS 2-10. 


APPENDIX C 


APPLICATION REQUEST FOR l/o 
SEQUENCE OF EVENTS 


CPU 


MSC 


I 1 

1 1 2 6 7 1 


bce(s) 




■ P iLi:& X f ER , 


I 

I 


A. FCOS STARTS REQUEST. 250y-300p 


1. TIME FROM FCOS READYING THE REQUEST 0-300y AVG. 73y 
UNTIL MSC STARTS ON REQUEST 


2. 

MSC 

SET UP TIME 


150y-220u AVG. 172y 


3. 

BCE 

SET UP TIME 

WRITE-I65y/BCE PROGRAM IN CHAIN 
READ - 200 v+200u/bce program in chain 

4. 

BUS 

SPEED 


33y /16 -bit word 


5. 

BCE 

CLEAN-UP TIME 


66y 


6. 

MSC 

BCE 

RECOGNITION OF 
COMPLETION 

DEU^ 

FC, 

PMU BUSSES 164-81Q0p^ avg / 
ICC BUSSES 20-400y^ avg 9: 

[62y 

)y 

7. 

MSC 

CLEAN-UP TIME 

50-65y AVG 58y 



8, FCOS SERVICES OF l/o INTERRUPT 

AND DISPATCHING OF TASK IF IT WAITED, 


RANGE OF TIMES WITHIN lOP Q-7) : 

DEU, PMU REQUEST: 

MIN .^3 MS + BCE SET UP (3) + DATA TRANSFER (^) 
MAX 8.75 MS + BCE SET UP (3) + DATA TRANSFER (4) 
FC, ICC REQUEST: 

MIN .29 MS + BCE SET UP (3) + DATA TRANSFER (4) 
MAX 1.05 MS + BCE SET UP (3) + DATA TRANSFER (4) 
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Objectives and Accomplishments 

The objectives of this analysis effort were as follows: 

• To further evaluate the SDL’s ability to provide real time 
responses to PC ALT I/O 

• To identify Host CPU utilization ^ 

• To analyze optimization of the PDA2 data collectxon buffer 

size. 


The above objectives have been achieved using analyzed data 
from computer simulation runs based on the following; 

• A model representing the current SDL Host & FEID Designs 

• A full minor cycle ALT PC I/O Profile, for Approach and 
Landing phase, (Reference 1) as opposed to the Plight 
Critical I/O Profile used in the Interim Modeling Analysis. 
The I/O Profile includes minor cycle sample variation and 
DEU traffic but not MM traffic because MM is not accessed 
during Approach and Landing Phase. 

• Measurements of ALT Math Model execution times and output 
calibration processing time (Attachment I) . 

• Host-to-PEID PDAl Traffic Profile (Attachment II) . 

• Control Program Services supplied by MPSM, Systems Analysis' 
simulation model of EOS. 




Results 


SDL Response Based on model simulations, the current 

support real time response to PC commands 
7 SSt of"’?? The total number of real time minor cycles was 

lySU^LMti^ttL^ ?nS^loll^S!n“°S:°' 

«* A 3.3 ms increase in Pass 2 Math Model execution times 

timtt! estimated math model times with actual measured 

• i“ output calibration processing 

time also Ly using actual measured times. " 

• A copection to Systems Analysis SDL Model desian to 
Model execution, instead of after Pass 1 Model execution 

breakdo^ of SDL response times. Interim Modeling Analysis results 

o5°th^ qm response times averaged 20.7 ms. but the components 
the SDL response have increased since that study. Table 1 
presentes a comparison of previous and current SDL design results 
with EOS overhead included in the response times results 

Since the current design does not support real time, two design 
changes as described below were analyzed: ^ 

• Design Change 1 (DCl) - Calibrate Pass 1 Math Model output 

after Pass 1 Math Model execution. ^ 

• Design Change 2 (DC2) - Calibrate Pass 1 Math Model output 

SS?h SoSel"Le;l?ion? 1 

Table’'^“^0«1ho:fl^ III JSvincrSI 

!nlre“by%!st^ 

3.2 CPU Utilization - The CPU utilization for the SDL in FC 
Mode IS summarized below: 


Components 

SDL 

EOS 

TOTAL 


Average CPU % 

79.3 
5.0 

84.3 
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The total CPU utilization ranged from 72.3 to 9’ « ia 

si* "" approaching «algn glweIJ^e®lf 

Utilization IS expected to increase with the addition of 
user aids and background activity. Thus any tunino of the ^ 

system must be considered in ligL of the dplTol S?iuLtion. 

The EOS CPU utilization is low because it represents only a 
one second steady state environment for the simulation job steo 
with no user aids active. This EOS CPU utilization can't blSed 
as a general figure for EOS usage by the SDL. 


3.3 PDAl Buffer size - To analyze optimization of the PDA2 data 
collection buffer sizes, four cases of the SDL model were run varvincr 
the Priority and Non-Priority Data Collection buffer sizes. The 
results of these cases are summarized in Table 3. The results shows 
that more real time minor cycles and lower SDL response complete 
tmes can be achieved by varying the buffer sizes. Although case 4 
shows profitable results over all, the buffer size of 2048 bytes 
increases the probability for a long hold off of a priority buffer. 
The non-priority buffer size of 1024 is suggested since this buffer 
size is the same for RTLOG and will balance I/O overhead with hold- 
off potential. 


This PDAl buffer size analysis indicates that the SDL can be 
tuned, but tuning is very I/O Profile dependent. 



Conclusions and Recoanmendations 


This analysis of the current design of SDL for the ALT FC Mode 
has lead to the following conclusions: 

• SDL design does not currently support real time. 

• The SDL can be "tuned** to meet real time support. 

The SDL response time can be improved by as much as 8.3 ms by 
implementation of the following recommendations: 

9 Reduce critical path elapsed time by overlapping some Pass 2 
model CPU with PDAl I/O. 3.7 ms savings) 

• Transfer Output (Header + Data + Filler) of Pass 1 Math 
Models after Pass 1 Math Model execution. (~ 1.8 ms savings) 

• Calibrate Pass 1 Math Model output after Pass 1 Math Model 
execution. (~ 1.3 ms savings) 

• Reduce PDAl transfer time for real time runs by reducing 
discrete and analog data VBS buffer control word overhead 
(~ 1.0 ms savings) 

• Reduce critical path math model CPU by tighter code 

0.5 ms savings). 

The following concerns must be addressed to avoid problems in the 
future: 


• The need for real time runs and the affect on CPU and 
response times during 

• user aid activity 

• background activity 

• host substituted DEU/MM I/O 

• Further increases in the EOML time due to FSW design changes. 

• SDL response time should be targeted < 20 ms to allow for 
growth and safety factors. 

• Time period of at least 3.6 ms in every minor cycle where the 
data in the Variable Buffer Storage (VBS) is not homogeneous. 
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FIGURE 1 


CURRENT DESIGN SDL RESPONSE TIME BREAK DOWN 
(TIMES IN MILLISECONDS) 


TOTAL ELAPSED SDL RESPONSE TIME 


RANGE 

23.0 - 25.7 J 

AVERAGE 

1 

o> . 

1 

^ 24.6 

HOST 

STARTUP 

TIME‘ 

PASS II 

MODEL EXECUTION 

PASS I AND 
PASS II 
OUTPUT 
CALIBRATION 

pdaI 

TRANSFER 

^Z.O N 


(f ^'4 

< 7.1-7.5> 

V 7 

2.4 

10.5 

3.1 

7.2 


SDL RESPONSE COMPLETE TIME (FROM START OF MINOR CYCLE): 
RANGE: 38,^ -^3.8 average; 41.2 


NUMBER OF REAL TIME MINOR CYCLES “ 7 

SDL RESPONSE COMPLETE TIME/ELAPSED MINOR CYCLE DIFFERENCE FOR 18 NON-REAL TIME MINOR CYCL 

range: 0.1 -3.3 AVERAGE 2.0 


^STARTS WHEN DATA COLLECTION OF EOML DATA HAS COMPLETED; AVERAGE FET=16.6MS (rANGE= 

14. 3-18. 7ms) 

SOURCE: SDL MODEL BASE CASE RUN 6/6/75 


Table 1 

Comparison of SDL Response Time Averages 
(Times in Milliseconds) 


SDL Response Catecfor 




Flight Elapsed Time for 
EOML Data in ^DA2 Data 
Collection Buffer 


SDL Startup Time (PDA2 
Transfer + Input Cali- 
bration) 


Pass II Model Execution 
T:'jne (Includes SLINKER 
overhead) 


Pass I & Pass II Output 
Calibration Time 


PDAl Startup/Transfer 
Time 


SDL Response Complete 
Time (Includes task 
commun ica t i on/ 1 inkage 
overhead) 


Previous 

Results* 

3/5/75 


10.5 


Current 

Design** 

6/6/75 


16.6 


Variance 


+ 6 . 1 ^ 



1. Flight Software I/O Profxle differences 

2. Increase due to using measured math model execution time 

3. Increase due to change in output calibration time of 18y s/data 
item to 23y s/data item and design change 

4 . Previous results based on hand calculation 

*Source; Interim Modeling Analysis - Final Report (Reference 2) . 

**Source; SDL Model Run 6/6/75 


























Table 2 

SDL Design Changes Response Statistics 
(Times in milliseconds) 


SDL Response Categor; 


SDL Response Time 


Current Design Design 

Desian^ Change 1^ Change 2^ 


23.0-25.7 22.5-24.0 21.0-23.5 


22.1 


SDL Response 
Complete 


38.4-43.8 


37.3-42.3 


40.0 


35.9-41.3 


38.7 


SDL Response Complete 
Time/Elapsed Minor 
Cycle Differences 
for Non-Real time 
Minor Cycles 


. 6 - 2.2 


0.5-0. 8 


0.6 


Number of Real time 
Minor Cycles 


Number of Non-Real 
time Minor Cycles 


Average Pass 2 Output 
Calibration Time 


Average PDAl Transfer 
Time 


CPU Utilization 


.2 


84.3% 


.2 


84.5% 


90.1% 


R- 

■range 

A- aver age 


1 

Source: 

SDL Model 

runs 

5/20/75 

2 

Source; 

SDL Model 

runs 

6/6/75 

3 

Source: 

SDL Model 

runs 

6/11/75 































TABLE 3 




mUm 

mUi2) 

- ^f2i/102‘l) 


AVERAGE 

RANGE 

41.3 

38.^1 - 

41.3 

3SA - 

40.9 

37.8 - 

40.7 

37.8 - 

40.6 

37.8 - 



number of 

REAL TIME 
MINOR CYCLE.S 

43.8 

7 

43.7 

7 

43.7 

10 

43.2 

11 

43.2 

11 


*(xxx/yyy) = priority/non~priority data collection buffer sizes 

IN BYTES 


SOURCE: SDL MODEL SIMULATION RUNS 5/19 - 5/21/75 
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ATTACHMENT I 


ALT HOST MODEL EXECUTION SEQ UENCE SIMULATED 


MODULE 


SMDLGACS 

SMDLENV2 

SMDLGSEN 

SMDLGLDS 

SMDLENVl 


MODEL 


ISMDLGNAV 


SMDLSPMU 

SMDLRCLK 


I MU (2) 

RGA 

NLA 


eomQ) 

ERVl 

ATM 

WND 

GRA 

aerQ) 


IMU(l) 

ADS 

PMU 



W'M: 


MEASURED 

i^U/jEXEC. 

2.200 

.270 

sjol 

5-25th mc 


m 


EXECUTION 

PHASE 

MEASURE] 

PROGRAM 

SI7P 

II 

6k 

II 

,2k 

II 

3.5k 

II 

« Zk 

II 

0.5k 

II 

1,0k 

I 

1.0k 


1 : 8 ^ 


2.0k 




SOURCE; SDL DEVELOPMENT PERSONNEL^ 4/14/75 


- 11 - 




ATTACHMENT II 


h.f 


1 li 


■ i-.' V..J 


■u 


ORlGlNiU. PAGE 


or 'iiiE 

13 POOR 


ALT H0ST~T0-FEID_BDAI_TRAFFIC PROFILE JlOilELED 


NUMBER OF WORDS _ab“EITT 


LOAD MODULE?” 

PARA lil£J£BS 


CALIBRATED. 


TOTAL OUT^ 


, CYCLES OUTPUT ^ 

..(ALL^=i. I HSU J . 5) 


PHASE II MODELS 

SMDLGACS/ 

ACS FDBK. SIG, 
ACS DISC, SIG. 

SMDLENV2/- 

smdlgsen/ 

imu(2) 

RGA 

NLA 

RGA DISC, 

PHASE I MODELS 

smdlglds/lds 

SMDLENVl/- 

smdlgnav/ 

TAC 

MLS 

RAD 

ADS 

nav disc, 

CSB DISC, 

MAN CONTROL 
EDS 

smdlspmu/pmu 


28 

0 

NONE 


NONE 
NONE 

15 

c 

1 

2i 

INCLUDED WITH 
CSB DISCRETES 
0 

30 

2 

0 


152 

ALL 

22 

ALL 

NONE 

n/a 


ALL 

60 

ALL 


ALL 

30 

ALL 

NONE 

n/a 

NONE 

n/a 


ALL 

30 

3,8,1348.23 

1 

ALL 

ALL 


n/a 

54 

DEMAND RESPONSE 

62 

DEMAND RESPONSE 

6 

DEMAND RESPONSE 

42 

ALL 


SOURCE: SDL PERSONNEL 3/75 

^INCLUDES FILL^ HEADER^, & FEID BUFFER CONTROL WORDS 
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REPRODUCIBIIOT OF THE 
:al fags m POOS 


PURPOSE AND SCOPE 


This report covers the results of the DEU Controller study, 
completed 3/26/75, and the DEU Controller/FEID study, completed 5/19/75 
The purpose of these studies was to evaluate the DEU Controller under 
worse case loading conditions. 

The scope of this study was limited to a DEU Controller stand- 
alone case and DEU plus FEID with OFT worse case I/O Profile cases. 


STUDY OBJECTI^/ES 


The objectives of this study were to determine: 

1) DEU Controller CPU Utilization 

2) Response times of various DEU commands. (MODE STATUS, 
KEYBOARD REQ & MEM FILL) 

3) The response time to the first word of a KEYBOARD request. 

The results of these studies are discussed under study findings. 

Also additional statistics are presented for: 

1) AGE/PDA2 controller CPU Utilization - This includes only 
PDA2 data collection activity. 

2) Data Collection Response times from the start of Data 
Collection until the DEU Controller level 1 interrupt 
occurs. 

3) PDA2 Data Collection response times measured from the time 
a full buffer is ready for transfer until the PDA2 transfer 
complete interrupt occurs. 


METHOD 


The first study was conducted using a discrete model of the DEU 
Controller software and its hardware interfaces {Case 1) . The DEU 
Controller model is based on the design reflected by References 1-4. 
This model was combined with the current FEID model for the second 
study (Cases 2 and 3) . FEID model is based on the design reflected 
in reference 5. Case 3 was run for comparison with case 2 to deter- 
mine the impact of DEU traffic on PDA2 buffer response times. 

The configuration used in these studies are summarized on Chart 1 . 
The number of real and virtual DEU's shown were included in all Poll 
and Graphic update sequences. 



Case 1 

Case 2 

Case 3 

DEU Traffic 

■■■ 

nHim 


FEID Model Included 

No 


Yes 

Num Real DEU's (Poll and 
Graphic Update) 

3 

3 

1 

Num Virtual DEU's (Poll and 
Graphic Update 

1 

1 

0 

Simulation Time 

BHHH 

1 

1 

1 sec . 

Poll Rate 

100 ms 

100 ms 

100 ms 

Total Positive Responses 

5 

5 

0 

Graphic Update Rate 

100 ms 

100 ms 

1 sec 

Graphic Update Word Count 

509 

509 

300 


STUDY CONFIGURATION CHART 
CHART 1 
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STUDY FINDINGS 


^ siainmarizes the overall controller CPU utilization. 

Data Collection responses for all modeled cases 
Tables 2 , 3 and 4 show detailed command responses for each modeled 
case . 


The DEU Controller CPU utilization is under 10% for all modeled 
cases. The CPU utilization for the PDA2 controller includes only Data 
Collection traffic with no AGE or discrete traffic. Case 1 shows 
a low PDA2 CPU utilization because lower process times were used 
for this earlier case. 

Channel Controller Queue CCCQ} was stopped twice (awaitina 
4 case 1 only. The CCQ stopped for ^ 
1690 seconds on a KEYBOARD REQUEST and for 1184 seconds on the follow- 
xng KEYBOARD ECHO. These delays in getting buffers arl cL^d g ” 
S processing for MEMORY FILLS for DEU's 1, 2 and 3 durina 

up in the CCQ of 39 words. The CCQ stack can handle 128 words before 

f^°P Flight Computer. This traffic case 
extreme and are not likely to be encountered 

100 mil?i'-^RonnH^°”ii responses from all 4 DEU's on the same 
2 cycle do not cause the CCQ to stop because 

the Flight Computer timing between KEYBOARD REQUESTS separates these 
activities enough to prevent buffer depletion. ^ 

In Table 1, average response times in micro seconds are shown 
or each command type. Line 1 for each command shows responses 
which are not perturbed by other controller activity! Linerfand 
L hou''o?f“J “"^roller for othe? DEu“Slivl?f 

eT - ?u“-of^ii;: Ji?L:r 

?f ?DA2 Data Collection responses for Case 2 and 


REFERENCES 


1 . 
2 . 

3. 


DEU Controller Program Flow Charts from Bill Carter 10/10/74. 
lOPI Flow Hardware Flow Charts from John King 10/30/74. 


Telephone 
1974 and 


aan!-m“hl5?5!“'' ■'“9 Dec. 
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REPRODUdBILIiY OF THR 
OR1GI1V.U. FAGS IS POOil ' 


STUDY SUMMARY 



3-26-75 

Study 

DEU 

5-19-75 

Study 


Only 

DEU + FEID 


Heavy 

Traffic 

Heavy 

Traffic 

Light 

Traffic 

Total Time Simulated 

Case 1 
2 sec. 

Case 2 
1 sec . 

Case 3 
1 sec • 

DEU Controller CPU Utilization 

4.52% 

5.02% 

.76% 

Level 0 Utilization 

NA 

1.11% 

.14% 

Level 1 Utilization 

NA 

1.17% 

. 16% 

Level 2 Utilization 

NA 

2.57% 

.29% 

Level 3 Utilization 

NA 

. 15% 

. 15% 

PDA2 Controller CPU Utilization 

1.39% 

4.26% 

1.00% 

DEU Controller Queue Activity 




CCQ Maximum Content (Wds) 

39 

4 

1 

Total Traffic (Wds) 

42989 

21510 

322 

Level 0 Queue Max Content (MSGS) 

1 

1 

1 

Total Traffic (MSGS) 

265 

145 

21 

Level 1 Queue Max Content (MSGS) 

1 

1 

1 

Total Traffic (MSGS) 

294 

162 

27 

Level 2 Queue Max Content (MSGS) 

5 

4 

1 

Total Traffic (MSGS) 

175 

95 

11 

Level 3 Queue Max Content (MSGS) 

1 

1 

1 

Total Traffic (MSGS) 

8 

5 

5 

DEU SIO Queue Activity 




DEU 1 Maximum Content (MSGS) 

2 

2 

1 

Total Traffic (MSGS) 

34 

20 

6 

DEU 2 Maximum Content (MSGS) 

1 

2 

1 

Total Traffic (MSGS) 

31 

20 

5 

DEU 3 Maximum Content (MSGS) 

1 

1 

1 

Total Traffic (MSGS) 

31 

17 

5 

MODE STATUS Avg. Resp. 1 

253 

254 

252 

2 

1468 

- 

— 

KEYBOARD REQUEST Avg. Resp. 1 

3425 

3259 

- 

2 

17284 

— 

— 

KEYBOARD REQUEST 1st wd 1 

1960 

1964 

- 

2 

2483 

- 


Avg. Resp. 3 

15994 




(Table 1 Continued on Next Page) 
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STUDY SUMMARY (CONT. ) 



3-26-75 

Study 

DEU 

Only 

Heavy 

Traffic 

5-19-75 

Study 

DEU + FEID 

Heavy 

Traffic 

Light 

Traffic 


Case 1 

Case 2 

Case 3 

ECHO CHECK Avg. Resp. 1 

3237 

3235 


2 

1776 

— 

_ 

3 

- 

20244 

_ 

MEM FILL (509 wds) 1 

35301 

35143 

— 

Avg. Resp. 2 

24069 

24566 


MEM FILL (300 wds) 1 

20481 

- 

20403 

Avg. Resp. 2 

10916 

- 


PDA2 ~ Buffer Response Times 




HIGH PRIORITY DATA COLL. 




(5 WORD BUFFERS) 

— 

950 


PRIORITY DATA COLL. 




(78/79 WORD WEIGHTED 




AVERAGE BUFFERS) 

— 

550 

498 

NON-PRIORITY DATA COLL. 




(256 WORD BUFFERS) 

i 

1 

1330 

1316 


■Table 1- 


DEO RESPONSES CASE 1 


Case 1 (3-36-75) 

DEU 

NUM 

Respor 

jtse Times 

in usee. 

DEU Controller Only 

DEVICE 
(1-3 REAL) 
(4 VIRT) 

MSGS 

AVG 

LOW 

HIGH 

MODE STATUS REQUEST 

1 

20 

252 

249 

255 


2 1 

20 

1468 

1462 

1478 


3 ! 

20 

253 

248 

255 


4 

20 

254 

250 

267 

KEYBOARD REQUEST (Full 
MSG) 

1 

2 

17284 

17276 

17291 

2 

1 

3240 




3 I 

1 

3264 

— 

— 


4 1 

1 

1 

3772 

- 

- 

KEYBOARD REQUEST (1st 
word) 

1 

1 1 

i 

2 ; 

15994 

15993 

15995 

2 

1 

1953 1 




3 

1 

1967 

— 



4 

1 

2483 

! 

- 

ECHO 

1 

2 

3232 

3231 • ! 

3232 


2 

1 

3243 

1 

— 


3 

1 

3238 

— 

— 


4 

1 

1766 

- 

- 

MEMORY FILL (509 wds) 

i 

1 : 

21 

35671 

34230 ; 

35844 


2 

20 

34941 

34903 

34966 


3 

20 

35293 

35257 

35316 


4 

20 

24069 

24010 

24149 

DATA COLLECTION FOR 

1 

21 

2335 

1876 

2366 

MEM FILL 






2 

20 

2214 

2192 

2258 

(510 wds) 

3 

20 

2354 

2322 

2384 


4 

20 

2343 

2327 

2369 

MEMORY FILL (300wds) 

1 

1 

20506 


_ 


2 


20517 

— 

_ 


3 

4 

!i 

1 

20420 

10916 

1 

- 

— 

DATA COLLECTION FOR 

1 1 

1 

1264 


i 

MEM FILL 







2 

1 

1424 



(300 wd s ) 

3 

1 

1248 

— 

_ 


4 

1 

1019 

- 

- 


-Table 2- 
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DEO RESPONSES CASE 2 


Case 2 

DEU + FE ID/HEAVY 

traffic 


MODE STATUS REQUEST 


keyboard REQUEST 
(Full MSG) 


KEYBOARD REQUEST 
(1st word) 


ECHO 


MEMORY FILL (509 wds) 
(No Occurrance of 
300 wds for this 
case 

DATA COLLECTION FOR 

mem fill 

(510 wds) 


PDA2 Data Collect 
Response ~ 

HIGH PRI DATA COLL. 
(5 WORD BUFFERS) 

priority data coll. 

(78 WORD WTD AVG 
BFRS) 

NON-PRI DATA COLL 
(256 WORD BUFFERS) 


DEU 

NUM 

DEVICE 

MSGS 

(1-3 REAL) 


(4 VIRT) 


1 

10 

2 

10 

3 

10 

4 

10 


1 


3 

4 


2 

3 

4 

1 

2 

3 

4 

1 

2 

3 

4 


2 

3 

4 


10 

10 

10 

10 

10 

10 

ID 

10 


50 


10 


1887 

24832 


24 

97 


*SIO to lOPI held off 
**Values Corrected for 


by MEM FILL between 
78 Word Avg Buffer. 


Response Times in nsp>n. 


AVG 

LOW 

HIGH 

257 

252 

252 

253 

248 

247 

248 

249 

300 

255 

254 

255 

3239 

3236 

3246 

3283 

3254 

3293- 

3273 

1949 

1948 

1949 

1985 

1957 

1973 

1997 

3243 

*2024fJ 

3227 

3249 

20239 

3237 

20249 

34884 

35096 

35448 

24566 

34822 

34623 

35210 

22901 

35035 

35260 

35563 

25039 

2668 

2509 

3190 

2638 

2676 

2648 

2618 

2630 

2605 

2673 

2749 

2680 

950 

236 

1401 

**550 

**487 

**785 

1330 

1273 

1697 


KBD REQ and ECHO 


-Table 3- 
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Case 3 

DEU + FE ID/LIGHT 
TRAFFIC 


MODE STATUS REQUEST 


KEYBOARD REQUEST 
(Full MSG) 


KEYBOARD REQUEST 
(1st word) 


ECHO 


EE?IiOV>UGmiLITy OF TTiE 
OEiGINAL PAGE IS POOR 


DEU i^ESPONSES CASE 3 


DEU NUM 

DEVICE MSGS 

(1-3 REAL) 

(4 VIRT) 


Response Times. in usee 
AVG \ LOW HIGH 


MEMORY PILL (300 wds) 
(No occurance of 
509 words for this 
case) 

DATA COLLECTION FOR 
MEM PILL 

(301 wds) 


20403 


1326 


PDA2 Data Collect 
Responses 

HIGH PRI DATA COLL 
PRIORITY DATA COLL 
(79 WD WTD AVG BFR) 
NON-PRI DATA COLL 
(256 WORD BUFFERS) 


1972 


3072 


**498 


1316 


1270 


**Values Corrected for 79 Word AVG Buffer 
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1 . 0 Management Overvie w 

The findings of this study are summarised below: 

• Current job/hr rate is 5-8 jobs for SDL/FSW jobshop 

• Step PLMSUP requires 400K-600K and is active approxi 
mately 65% of elapsed time in a sample segment of 
3 obshop time 

• OPDEK seek time avg 22.88 ms. to 24.33 ms. 

• SYSAUX seek time avg 13.52 ms. 

• SYSR21 seek time avg 32.6 ms. 

• Region requests for FSIM and ICS are not excessive 

• varies from 10-30 minutes and 
IPL from 8-24 minutes. 


Based on the above findings and associated analysis, 
raendations are made for the following areas: 


recom- 


• Add job classes LMN to 2nd jobshop initiator 


* VTOC, CATALOG, and permanent data sets on certain 
disk volumes (See Section 7.0 for specific recommendations) 

• Modify PSW/SDL Proc's to improve temporary data set 
efficiency 




Improve handling of scratch packs and permanently restored 
packs for jobshop 


• Update the SDL simulation jobstep region estimating 
cedure frequently. ^ 


pro- 


in thf conducted 


• Analysis tools and procedures for more efficiently con- 
ducting throughput studies 

• Regular analysis of FSW/SDL jobshop by Systems Analysis 

0 PLMSUP - to permit multijobbing or reduce elapsed time in 
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• Frequent "Figure of Merit" studies on SVCLIB 

• Modxfication pf Job Stream Manager to permit automatic 
oacKlog aging. 

2.0 Purpose and Scone 


study was to investigate FSW and SDL 
turnaround and make recommendations to achieve improvements 
Primary emphasis was placed on throughput (jobs/jobsteps per hour) 
^provements which could be easily identified and qSkly ?Lli“Id 
The impact or changes already made can't be completely evaluaS ’ 

analysis. Areas which need additional effort 
study to further improve jobshop turnaround are identified. 

study has been limited only by the amount 
of time allocated for completion of the study. 


3 . 0 Ob j ectives 


The planned objectives of this study were: 


a) 


c) 


Manager (JSM) matrix and the 
initiator class assignments and 
recommend changes where necessary. 


b) Measure and analyze jobshop disk volume seek times 
and recomm.end alternative data set allocations to 
reduce seek times. 


Detemine SDL simulation jobstep actual region 
requirements and reconcile an estimated FSIM reaion 

actual requirement of 


d) Obtain and analyze performance measurement data on 
five typical jobs. 

inSK^L?^® components of jobshop turnaround, 


Deck submission until arrival in the RTCC. 

T^e spent in the RTCC waiting to be run. 

Time spent waiting for print to complete after 
execution is complete. 

Time from print complete until output is returned 
to programmer's desk. 


of these objectives analysis of the five sample jobs (item d) 
and quantification of jobshop turnaround components (item e) were 
not pursued to completion* In depth tracking of jobs through the 
processes indicated would have required more time than could be made 
avaxlable xn this study. However, a brief review of the procedures 
dxd not dxsclose any significant problems in this area. 


4 , 0 Method 


This analysis has been conducted using available analysis tools 
as follows: 

Jobshop throughput/turnaround - System Management Facility 
(SMP) , System Online (or Log Data set) 

Job Performance - ?VSC, Load Module and Task option 
DASD performance - ASC, I/O Trace option 

Simulation Jobstep Region Requirements - Core Dump and Region 
size estimating procedure for SDL version 1 (reference 1) 
Job Stream Manager ~ Statistical output from Job Stream Manager 


5.0 Findings 


The findings in this section address the following areas 

• Job Throughput 

• Job Stream Manager 

• Disk Volume Activity 

• FSW/SDL Cataloged Procedures (Proc's) 

• SDL Simulation Jobstep Region Requirements 

• Operational Procedures/Scheduling 

5 . 1 Job Throughput 


The number of jobs/jobsteps per hour varies with each jobshop 
period. The job/jobstep rates are meaningful only if all background 

taken into consideration. The analysis 
of SMF data has shown that the current job rate falls in the range 
of 5 to 8 jobs per hour (range of jobstep rate is 26 to 64 iob- 
steps per hour) , 


Using the first 1.5 hours of a 7.3 hour FSW jobshop period 
(8 p,M. on 4-30-75 to 5 A.M. on 5-1-75) an analysis was made to 
determine how the main core resource was being used. Figure 1 
(Job Throughput) graphically depicts the elapsed time of the Program 
Library Management Supervisor (PLMSUP) jobstep in relation to the 

in the system. In the sample period observed, 
the PLMSUP main core region varies from 400K to 600K and the average 
step elapsed time was about 6 minutes. Allocating main core for 
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prevented multi jobbing 

of similar steps for 65% of this segment of jobshoo time A sttidv 

of ways to make PIMSUP multi jobbable or reduce elapsid time 
system is recommended. exapsea time in tne 

5-2 Job Stream Manager 

A study of the Job Stream Manager job class assianment matrix 

pfLreT'^X ?he ROS Depl. at the star? 

^ shows the 30 b class assignment matrix and initiator classes 

Stream Manager geSeJa^efre- 

ClLs "L"”wSI asJiSrr'^^® placed in a particular class. 

Class L was assigned in many cases because the estimated Toh 

bi^^th^ROS^DJot^ ^ matrix has been prepared 

by the ROS Dept, and implemented to better distribute the job^ 

classes. The new matrix will cause jobs of less than 2 4^and in 

minutes to be assigned to classes 1, j Ld K rlJp2??velv aLo 

30 b classes LMN should be added to initiator J2 to give better 

3°*’®- ’^e Job Stream Manager 

i? Pl^?e 2 ! ®“ 9 gested initiator class assignments are shown 

times in excess of 24 hours have been ex- 
several occasions. Currently, when jobs are back- 
logged from one jobshop period to the next. Operation! ?eads in th^ 
backlog 30 bs and allows them to start before reading in the new iob- 
stream to give the backlog priority in the svstem qinni ^ 

procedure for inputting jobs doesn't insure a priority for the backlog 
the newer 3 obs can crowd the older and longer jpbs to 4 rd the end 
of 3 obshop and cause them to become backlogged again. To prevent 

system from determining priority 
Sf 4 -« Stream Manager program may be modified to 

stamp incoming jobs and then assign a higher dis- 
patching priority and a more favorable iob cla<?<5 t*n -hvio 
This would insure the backlog bei^! rii'?L!t !lga?dS!s of ^h^ 
systera^*^ which the old and new jobstreams were loaded into the 


5.3 


Disk Volume Activity 


SysAUX^v!l!^es heaviest on the OPDSK and 

on OPDSK was 22 88 ??? measured cases, average disk arm seek time 

SDL jobshop. SYSAUX,^Lwlv!!”^!h<5w!d SU jobshop and 24.33 ms on 
on FSW jobihop anri4.73 mron time of 13.52 ms 

the higher average seek time nn Analysis shows that 

position of the VTOC in the FSW iob^hni^ caused by the relative 
position Of posmunent 
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JOB THROUGHPUT PLOT 


Mobshop 




RUN TIME 
IN HRS. 
(EXCLUDES 
SETUP) 

NUMBER 
OF JOBS 

NUMBER 
OF JODSTEPS 

JOBS/HR 



2.0 
*7.3 
6.4 
3 . 0 
1 . 6 

10 

48 

44 

24 

11 

54 

192 

181 

174 

101 

5.0 
6.6 
6.9 

8.0 
7.0 


JOBSTEPS/HR 

27.0 
26.2 
28.4 

58.0 
64.3 


PLMSUP STEP ELAPSED (NO‘ 
WALL CLOCK TIME PERIOD 


REGION WAIT TIME 


59.9 MIN 
92.0 MIN 



65% OF TIME 
PERIOD MAIN 
CORE WAS TIED 
UP WITH 400- 
60 OK REGIONS 
FOR PLMSUP. 




UUO W UMBER 


approx 1 1/2 HRS 




total job elapsed time (ihcluding region wait and job OVERLAP) 
OVERLAp“''“'' (includes REGION WAIT AND JOB 




X - " X 


KSTIMATEIJ ELAPSED TIME PLMSUP 
AND WITH NO JOB OVERLAP) 


JOBSTEP 


(EXCLUDING REGION WAIT 


• Figure 1 
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JOB STREAM MANAGER MATRIX 
AND INITIATOR CLASS ASSIGNMENTS 


JOB CLASS DEFINITIONS/CLASS 

h 

I 

j 

K 

L 

M 

N 

0 

EXECMAIN 

250 

m 

mo 

400 

600 

1000 

1000 

1000 

EXECLCS 

3000 

3000 

3000 

3000 

3000 

3000 

3000 

3000 

9-trk 

1 

2 

2 

2 

4 

8 

8 

8 

7-trk 

0 

0 

0 

0 

0 

0 

0 

1 

TAPES 

1 

2 

2 

2 

4 

8 

8 

8 

SYSOUT 

6000 

6000 

6000 

6000 

6000 

6000 

6000 

32000 

WORK 

6000 

6000 

6000 

6000 

6000 

6000 

6000 

32000 

TIME 

15 

2 

4 

10 

15 

30 

1440 

1440 

PRTY 

15 

15 

15 

15 

15 

15 

15 

15 


init.jI.^^Cdahijk) 

init.j2>,^(danmlkjih) 

INIT. (LMNOE) 


figure 2 




case (see Figures 3 and 41 , Moving the VTOC from cylinder 0 to 
the center of the data set activity would reduce disk arm movement 
in the FSW jobshop case. The SDL jobshop OPDSK voltime does have 
the VTOC in the center of the volume, but permanent data sets are 
arranged between it and the temporary data sets. Arm movement over 
these unused data sets causes a higher average seek time. Scratching 
VTOC or clearing the pack before clipping it to OPDSK would alle- 
viate this situation. 

Figure 5 shows a SYSAUX volipe with VTOC and data sets arranged 
for more efficient accessing, which results in an average seek time 
of 9-10 ms less than that observed on OPDSK. 

Analysis of the access distribution and arm movement on the 
SYSR21 voliame indicates that SVCLIB, the VTOC and JOBQUE are 
accessed most frequently (see figure 6} . Based on the above find- 
ing, the ROS Department conducted a "Figure of Merit" study to 
determine which SVC modules should be made resident. A new Resident 
SVC list has been included in the latest ROS release and should 
result in at least 6% fewer accesses to SVCLIB than with the pre- 
vious list. Since the jobshop environment is constantly changing 
"Figure of Merit" studies should be conducted at regular intervals. 

Improvement in the average seek time on the SYSR21 volume is 
„ ' possible by arranging SVCLIB, the VTOC, CATALOG and JOBQUE together 
on the volume. 

5.4 FSW/SDL Prop's 

Analysis of SMF data has shown that the high speed main core 
resource is not always used most efficiently, especially when small 
I/O bound jobsteps and large CPU bound jobsteps compete for this 
resource. Many I/O bound jobsteps require smaller regions and use 
comparatively little CPU time, but occupy main core during I/O 
wait time. These jobsteps with smaller regions increase the possi- 
bility of core fragmentation which will prevent the larger CPU 
bound jobsteps from starting. Relocating these steps to LCS will 
not significantly impact their performance but will free up main 
core for the larger CPU bound steps. 

At the time this study started, a list of program steps to be 
relocated to LCS was already being prepared (see figure 7) . 

Evaluation of the impact of these changes cannot be determined un- 
less additional jobshop throughput analysis is performed. 

A sample FSIM job run was analyzed to determine the extent 
and kind of temporary data set activity. This job of four steps 
(compile, Pre— Sim, Simulation, and Post— Sim) caused the allocation 
of GO temporary data sets. Figure 8 summarizes the use of these 
data sets and the average measured CPU cost of the allocate and 
scratch services. Although the actual allocation and scratch of 
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SDL PROC REGION CHANGES 


PROC 

PROC STEP 

PROGRAM 

OLD 

REGION 

NEW 

REGION 

*CYCTRIOI 

CYCIl 

SMTRIOED 

150K,0) 

(,150K) 


CYCI2 

QMSMOVER 

C20K,50K) 

(,150K) 


CYCI3 

QMSMOVER 

(20K,50K) 

(,150K) 


CYC 14 

QMSMOVER 

(20K,50K1 

(,150K) 

*CYCTRION 

CYCIl 

lEBGENER 

(200K,0) 

(,150K) 


CYCI3 

IEFBR14 

(2K,0) 

(,80K) 


CYC 14 

IEFBR14 

(2K,0) 

(,80K) 

*CYCTRIOO 

CYC02 

QMSMOVER 

(20K,50K) 

(,150K) 


CYC03 

QMSMOVER 

(20K,50K) 

(,150K) 


CYC04 

QMSMOVER 

(20K,50K) 

(,150K) 

PSWJSTPl 

JSTEP 

SMDLRJSC 

C0,150K) 

(,220K) 

*MOVER 

MOVE 

QMSMOVER 

(20K,100K) 

(,150K) 

SDLCOLTP 

PLMS 

PLMSUP 

(350K,350K) 

NC 


COLPRT 

QMBCOLPT 

(MAIN DE- 
FAULT) 

(,150K) 

SDLDTAB 

DTPLMS 

PLMSUP 

(350K,350K) 

NC 


DTAB 

REPDDTAB 

(0,500K) 

NC 

*SDLJSTP1 

JSTEP 

SMDLRJSC 

(150K,150K) 

(,220K) 

SDLDELG 

S2 

SMBJMDJS 

(50K,50K) 

(,150K) 

SDLPOST 

SI 

SMDLPOST 

(150K,50K) 

(,150K) 

SDLPLOT 

S2 

SMDLPINT 

(100K,50K) 

(,150K) 

*SDLTEST* 

STST 

REFCDARY 

(300K,500K) 

(350K,500K) 


NC=No Change 

*Changes for system growth only 


Figure 7 
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these data sets takes place outside the limits of the jobsteps 
within the schedular, reader, writer) the total CPU time 
used for these services is approximately 4.96 seconds. Compared 
to the 141 seconds of the job, this is an additional 3.5% of CPU 
t^e. The elapsed time for these services has not been determined. 
The impact for this activity is not only the CPU time overhead but 
the additional disk arm movement which can impact all jobs in the 
system. 


The allocate and scratch activity can be reduced by; 

• Elimination of any un-used DD cards from the Proc's. 
(This could occur if similar Proc's are used for 
different programming areas) . 


The use of dedicated data sets in the initiator Proc 
for those temporary data sets which are most frequently 
used. (SYSXN and SYSOUT data sets cannot be used in 
this manner) . 


5.5 SDL Simulation Jobstep Region Requirements 


Two main ^ questions were to be answered by this study regarding 
main core region requirements. First, are the requested regions 
excessive and second, why did a reported difference of 56K exist 
between the estimated and the actual requirements for an PSIM run. 

A mapping of main core usage was n\ade from core dumps of the 
FSIM and ICS modes for the SDL simulation jobstep for Rel 4.1 
version 4. The results of this effort are tabulated in Figure 9, 
which shows that the regions requested are not excessive . 

The actual data case in which a 56K difference was observed 
between the estimated FSIM core requirements and the actual core 
requirement was not available for analysis. However, the core 
requirements observed in the above study were compared with the 
calculated estimate from the procedure outlined in the release memo 
for "Release 4.1 version 1 of the SDL" dated 3-28-75 (Reference 1) 
as follows: 

SDL FSIM Mode 300K 

Closed Loop GN&C Math 
Models lOOK 

Flight program size 
(from Dump) 33K 

433K 
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TEMPORARY DATA SETS ACTIVITY 
FOR A FSIM JOB 



TYPE DATA SET 

NUM 

SYSOUT 

16 

TEMPORARY/SYSIN 

29 

TEMPORARY PASSED 

15 


60 



AVG 

EXEC 

AVG 

TOTAL 

FOR 

TOTAL TIME (IN 


TIME 

SERVICE 

MS.) FOR 60 


IN MS. 

IN MS. 

SCR/ALLOC 

SCRATCH 

20.8 

45.6 

2736 

ALLOCATE 

6.3 

37.1 

2226 

JOB ELAPSED TIME 
JOB CPU TIME 
60 SCR/ALLOCATE 


12 MIN 

141.78 SECONDS 
4.96 SECONDS 

4962 


Figure 8 
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SIMULATION STEP MAIN CORE USAGE 




(REL 4.1 VER 4) 

MAIN 

-CORE USED 

SUBPOOL 
ID 

USE 

FSIM 

MQDJE. 

ICS 

MQD.E 



251 


user's JOBLIB REENTRANT MODULES 

IOOk 

164k 

252 


LINK PACK AREA REENTRANT MODULES 

8k 

10k 

200 


REAL TIME TABLES 

6k 

6k 

199 


DYNAMIC SUBROUTINES j SYSTEM PARMS 

34k 

34k 

191/192 

RT QUES AND BUFFERS 

4k 

4k 

0 


MODE INDEPENDENT DATA BASE + BUFFER 
POOLS 

46k 

46k 



COMMUNICATOR 

18k 

30k 

50 


ENVIRONMENT MODELS 

50k 

* 

51 


GN&C MODELS 

28k 

* 

62 


FSIM 

22k 

- 

64 


MODE DEPENDENT DATA BASE 

98k 

70k 

67 


USER AIDS (hAL SIM TABLES) 

10k 

— 

MISC 


SP65/68 USER AIDS 

6k 

4k 

FREE 


FREE REGION CORE (AT TIME OF DUMP) 

_ZQk 

112k 

MAIN 

REGION 

REQUESTED 

500k 

480k 

MAIN 

REGION 

USED 

462k 

4Z6k 

MAIN 

REGION 

UN-USED 

38k 

4k 

*NO MATH MODELS WERE USED IN THE ICS RUN, 
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The actual core used by the Rel 4.1 version 4 run was 462K or 
29K more than estimated under the procedure. Time did not permit 
a detailed comparison of Rel 4.1 VI and Rel 4.1 V4 dumps, but these 
xndicstG tils ©stiinstxiig pJTOcsdujrs xiGsds to bs irsvxswsd 

and updated if necessary for each SDL release. 

5.6 Operational Procedure/Scheduling 

^ complete study of operational procedures and scheduling was 
beyond the scope of this task. However, certain areas which may 
improve throughput if attention is given them are discussed below: 

1 n initial set up time for a block of computer time can use from 
10 to 30 minutes depending upon the number of disk volumes to be 
mounted, restored or cleared, the problems encountered (e.g., tape 
errors) , and the number of other manual operator interventions 
required. A review of procedures for the use of permanently 
restored disk volumes is recommended, in conjunction with an 
inventory of such disk volumes. 

The time between IPL and start of the first job varies. Using 
the onlines, times of 8 to 24 minutes were observed. 

Assuming that this set up is necessary, users requiring the 
same set up and IPL options could be scheduled on consecutive 
blocks of computer time. In this way set up time could be reduced 
for users following the first user. 


6 . 0 Results 


Certain activities were found to be in process at the time this 
study started. Others were initiated as a result of this study. 
Those which are completed and in place now are listed below: 


• Job Stream Manager parameters - a new matrix was already 

being prepared when, this study began and is in place at 
this time (EOS 21.23). 

• Relocation of Proc steps to LCS - an update to PROCLIB 

was already in process and is in place at this time. 

• "Figure of Merit" study was conducted by ROS and a new 

Resident SVC list has been generated and is currently 
on the system. 


Systems Analysis concurs with the changes being made in the 
above areas. 


7 . 0 RecoTOmendations/Action Items 


The recommendations which follow are based on the data 
gathered for this study. Some areas may require some additional 
investigation or study before implementation. 

e Add job classes LMN to initiator 2 as follows (DAMMLKJIH) 

• Rearrange SYSR21 to group SVCLIB, VTOC/CATALOG and JOBQUE 
together . 

• Move VTOC and CATALOG (if applicable) to the center of 
activity on OPDSK, SDLAOl, SDLBOl, PSWAOl and SSWAOl 
volumes . 

• Move most active permanent data sets close to VTOC and 
CATALOG on volumes SDLAOl, SDLBOl, PSWAOl and SSWAOl. 

9 Use the SDIiMMl volume for temporary data sets because of 
its extremely low access frequency. 

® Initiate a procedure to insure that scratch disks (OPDSK) 
are clear or have the VTOC scratched before being used for 
j obshop , 

• Eliminate any un-used DD cards from Proc's. 

« Select temporary data sets (other than SYSIN/SYSOUT) which 
can be allocated as dedicated data sets in the initiator 
Proc ' s . 

® Update SDL Region Requirements estimating procedure for 
each version of the SDL if necessary. 

c Review procedures for use of permanently restored packs 
and inventory the current packs. 

To achieve and maintain maximum utilization of the RTCC job- 
shop resources, additional study efforts are necessary. The 
following can be done individually or together as a total effort: 

• Investigate tools and procedures for performing jobshop 
throughput and turnaround analysis to permit more timely 
idnetification of problems. 

9 Establish an analysis task to regularly monitor FSW/SDL 
jobshop (should include disk activity study) . 


Silowing"' to aooomplish either of the 

•• Reduce region requirements to permit multiiobbina 
{consider LCS buffering of module and tables) . ^ 

•® Reduce the step elapsed time to free up main core 

sooner (some of the changes which improve disk access 
efficiency will also help in this area) . 

task to perform "Figure of Merit" studies on 
jobshop at regular intervals (perhaps the need for thi'c= 
activity can be determined by a separate disk activity study) 

Investigate the possible modification of the Job Stream 
Manager to provide a date and time stamp capability for 
the automatic aging of backlogged jobs. Old jobs could be 


8 . 0 References 

3-28-75? 1 the SDI," by J. R. Gilliland 

2. ''SDL/PSM Jobshop ^rnaround Study - Initial Report" by 
J. R. McLean, 5/9/75. ^ 
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MANAGEMENT OVERVIEW 


Using Systems Analysis' simulation model of tlu' SOL, a sLuily 
of the SDL's sensitivity to the current PDA2 interface (I/F) manage- 
ment scheme for the 2FC and MFC modes of operation has been con- 
ducted. Analysis of simulation output reveals that: 

• End“of-rainor-loop (EOML) record holdoff due to PDA2 I/F 
contention can become Sufficient (14.8 ms maximum) to keep the 
SDL out of real time in the 2FC and MFC modes. 

• This holdoff can be reduced to 3.3 ms (maximum) by setting 
non-priority data collection record sizes to 256 bytes. 

Final PDA2 I/F tuning recommendations, based on SDL MFC performance 
analysis currently in progress, will be made at the Release 6 DDR 
in November. 


OBJECTIVES 


The objectives of this study have been to: 

(1) bound the expected effect of Master/Slave FEID con- 
tention for the PDA2 interface on the SDL's perfor- 
mance in the 2FC and MFC modes of operation, and 

(2) determine how PDA2 priority record throughput might 
be improved. 

Both of these objectives have been accomplished. 


FINDINGS 

Objective 1 - Bounding the Effect of PDA2 Contention 

For this study PDA2 I/F contention is measured in terms of PDA2 
holdoff time. Holdoff occurs in the 2FC and MFC modes when any l’DA2 
transfer from one FIMD cannot occur immediately because; the PDA2 
is busy with a transfei- from another FETD (see Figure 1, p. 2 )• 
Holdoff impacts SDL response performance when EOML transfers, which 
trigger Host processing, are delayed by non-priority trajisfers. 
Holdoff time is defined to bo the elapsed time from the time the 
last FEID's priorioty EOML data collection record is ready for 
transfer over PDA2 , until the time its transfer is actually started. 
Under the study's assumptions (Appendix A), the last EOML record in 
the 2FC mode is from the left slave FEID. In the MFC mode, the 
last EOML record is from the right slave FEID. 
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?nn i 1 holdoff times range fioin 

00 microseconds to 14.8 ms. in the environments represented by 

lllvl FFjn holdoff times shown occur when Master and/or other 

slave FEID EOML record transfers delay the last slave FEID's EOML 
transfer. The high holdoff times shown occur when EOML and non- 

and/or other slave FEID transfers delay the last 
modeling^^^ transfer. Variability between cases is atributable to 

• different missions (ALT vs. OFT) 

• different mcdos (2FC vs. MFC) 

- diffepnt flight computer I/O profiles (typical worst case 
vs. theoretical worst case) 

• different data collection record sizes (minimum vs. maximum) . 

holdoff times seen in cases 2-5 

? /n 20-25 ms. available for the Host to respond to FC 

t/2' performance is definitely sensitive to the current PDA2 
I/F management scheme. In fact EOML record holdoff can keep the SDL 
out of real time in the 2FC and MFC modes. 

Objective 2 - Improving Priority Record Throughput 

To improve PDA2 priority record throughput, three factors are 
analyzed with respect to their impact on interface performance: 

• data collection record sizing 

• equal opportunities for Master and slave FEID PDA2 transfers 

• priority /FIFO PDA2 I/F management logic. 

While these are not all of the variables available for interface 
tuning, they are logically straightforward, and are reasonable kinds 
of tuning to consider in this study. 

Since the effect of non-priority data collection sizing was 
h! differimt maximum holdoff times for cases l and 2, 

tuned versions of cases 1, 3, 4, and 5 wore run (cases 6-9 in 
Table 2, p 5 ) to further quantify this effect. That is, for cases 
6 9 priority record sizes were sot to 128 bytes and non-priority 
record sizes were set to 256 bytes and all other model run para- 
meters were left unchanged. The effect of this data collection 

tuning on PDA2 contention is reflected in the dramati- 
cal.. reduced (.9-11.5 ms.) maximum holdoff times shown. Clearly, 
the impact of PDA2 contention on SDL performance can be reduced 
through data collection record size tuning. 
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Table 1 


PDA2 HOLDOFF STATISTICS - INITIAL SIMULATION RUNS 


Case # 

Case Description^ 

PDA2~HoIdoff 

1 

Baseline ALT^ 2FC (128/512) 

'jjjotixrveQ (ins / 
. 2-1 . 9 

2 

1 

1 

2FC (128/1024) - case 1 with larger non- 
priority record size. 

.2-4.2 

3 

Theoretical ALT' 2FC (512/2048) 

.5-8.9 

4 

Baseline 0FT“ MFC (128/1024) 

. 4-6 . 1 

5 

Theoretical OFT^ MFC (512/2048) 

1.6-14.8 


Source: SDL MFC Simulation Model Runs 8/15-8/18/75 

^Numbers in parentheses represent priority and non-priority data 
3r©spsctiv0Xy • 

Reference 2 


collection record sizes 


(in bytes) , 


'Reference 2 with certa.r. flight computer I/O 
of the PDA2 interface n-anagement logic. 


(DEU and SM) 


timed to cause heavy transient loading 


**Reference 3 


^Reference 3 with certain flight computer I/O (DEU and SM) 
of the PDA2 interface management logic. 


timed to cause heavy transient loading 


I 

) 


Table 2 



PDA2 HOLDOFF STATISTICS - "TUNED” SIMULATION RUNS 


Case # 

Case Description^ 

Holdof f 
Range (ms) 

Improvement 

(ms) 

6 

Baseline ALT 2FC (128/256) - Tuned Case 1 

.2-1.0 

.9 

7 

Theoretical ALT 2FC (128/256) - Tuned Case 3 

.2-1.5 

7.4 

8 

Baseline OFT MFC (128/256) - Tuned Case 4 

.4-1.8 

4.3 

9 

Theoretical OFT MFC (128/256) - Tuned Case 5 

.4-3.3 

11.5 

10 

Baseline ALT 2FC (128/256) - Case 6 w/Priority/ 
FIFO I/F Management 

.2-. 5 

.5M1.4) 

'll"' 

Baseline OFT MFC (128/256) - Case 8 w/Priority/ 
FIFO I/F Management 

.4-. 8 

1.0^ (5.3) 


I 

1 


Source: SDL MFC Simulation Model Runs 8/19-8/21 


^Numbers, in parentheses represent priority and non-priority data collection record sizes (in bytes), 
respectively. 

^These savings are in addition to the savings realized in cases 6 and 8. The numbers in parentheses 
represent total savings for cases 1 and 4. 


























In evaluating the second PDA2 I/F performance (actor, cquaJ 
opportunities for Master and slave FEID transfers, the following 
PDA2 I/F management polling schemes were simulated: 


Master 

Left 

Master 

Left 

FE ID 

Slave 

FEID 

Slave 


FEID . 


FEID 

Master 

Left 

Master 

Right 

FEID 

Slave 

FEID 

Slave 


FEID 


FEID 


Since the current schveme allows two Master FE;ID transfers per slave 
transfer, the intent of these new schemes was to give the slave 
FEID{*s) the same number of chances as the Master FEID to transfer 
data over PDA2 . However , no improvement in PDA2 throughput was 
gained. This is because the new schemes did not eliminate the 
factors contributing to PDA2 holdoff, but merely effected a re- 
ordering of those transfers which delay the last FEID's EOMn record 
transfer. 

To evaluate the third tuning consideration, a PDA2 I/F management 
scheme was simulated which transferred data collection records on a 
priority/FIFO basis. That is, the oldest and highest priority 
record ready for transfer at the time the interface became available 
was transferred, regardless of the originating FEID. Using this 
scheme, cases 6 and 8 were rerun and additional holdoff reductions 
of .5-1.0 ms. (Table 2) were realized. These are small savings, 
however, especially when compared with the impact to the FEID pro- 
gram (expressed by FEID developers) to incorporate the priority/ 

FIFO scheme evaluated. Because of this poor benefit/cost relation- 
ship, adoption of this scheme is not recommended. 


RESULTS and RECOMMENDATIONS 

SDL performance in the 2FC and MFC modes has been shown to be 
very sensitive to the current PDA2 I/F management scheme. Fortu- 
nately this sensitivity can be reduced through tuning and without 
costly FEID design changes. For example, maxim\im PDA2 I/F holdoff 
times can be reduced from the 1.9-14.8 ms. range to the 1.-3. 3 ms. 
range just by setting non-priority data collection record size to 
256 bytes. Also, during this study, SDL PDA2 I/F tuning capabili- 
ties, other than those already discussed, were suggested by SDL 
personnel. Based on those suggestions, the following Systems 
Analysis action is recommended to determine the most effective way 
to tune PDA2 I/F performance: 


(1) As part of the MFC performance evaluation task currently 
in progress evaluate the effect of: 

• turning off non-priority data collection record transfers 
at various times during the minor cycle (e.g. , first 20 ras.; 
10-20 ms. into each minor cycle) 

• doing priority data collection in the Master FEID only 
(i.e., no slave FEID priority data collection). 

(2) Compare/include the tuning results from step (1) with the 
data collection record sizing results from this study to determine 
exactly how the SDL should drive the PDA2 I/F to achieve the best 
priority record throughput - 

The results of this additional PDA2 I/F analysis should be pre- 
sented with other MFC performance information at the Release 6 DDR 
in November . 


REFERENCES 

(1) "PDA2 Contention Sensitivity Analysis - Initial Report" by 
R. Stephen Carter, dated August 8, 1975, 

(2) "SDL FC Mode ALT Final Modeling Analysis - Initial Report" by 
Johnny E. Knight, dated April 7, 1975. 

(3) Attachment C to "FSW Processing and I/O Profiles" by G. D. 
Carlow dated 1/7/75. 
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APPKNULX A 


PDA2 CONTENTION SENSITIVITY ANALYSIS BASIS/ASSUMPTIONS 


(1) Systems Analysis' understanding of FEID PDA2 interface manage- 
ment scheme : * 

• 2FC Mode - At a four megacycle rate the interface management 

hardware will poll for PDA2 transfers in the 
following sequence : 

Master Master Left Slave Master Master Left Slave Master Master 
FEID FEID FEID FEID FEID FEID FEID FEID 

* MFC Mode - At a four megacycle rate the interface manage- 

ment hardware will poll for PDA2 transfer in the 
following sequence: 

Master Left Slave Master Right Slave Master Left Slave Master 
FEID FEID FEID FEID FEID FEID FEID 

Right Slave 
FEID 

(2) When a PDA2 transfer completes, polling for the next record to 
be transferred will resume at the point in the polling sequence 
where the last positive polling response was encountered. 

(3) PDA2 data collection record priority is not considered in either 
of the schemes described, 

(4) The flight computer /FEID combinations in the 2FC and MFC con- 
figurations modeled are assumed to be in synch with each other. 


*Source: Phone conversations with Jim Allen of IBM Huntsville, 8/8/75. 
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MANAGEMENT OVERVIEW 


The system design changes recommended in the SDL FC Real Time 
Problem Report (Reference 3) have been evaluated. The Systems 
Analysis simulation model of the SDL was used as the basis of the 
analysis. Individually, none of these designs allow the Host to 
achieve real time response to Flight Computer (FC) commands and 
keep CPU utilization under the 85 percent target. However, one 
combination of these design changes as described in Appendix B, 

SDD will allow the SDL FC Mode to meet real time and keep CPU 
utilization under 85 percent. Specific results of this combination 
include: 

9 SDL average response time is 19.5 ms 

• Average Host CPU utilization is 83.8 percent 

• Host computer meets real time in every minor cycle. 

As a result of the analysis the following recommendation is made: 

9 The SDL should adopt system design SDD because it supports 
real time with CPU utilization under 85 percent and mini- 
mizes impact to SDL design. 

Since CPU utilization is approaching 85 percent and there is a 
need for sufficient CPU availability for growth and non-cyclic 
activity it is also recontmended that: 

® Additional analysis be conducted to bound the CPU required 
for non-cyclic activity and to estimate CPU growth for OFT 

® A detailed review of model inputs and operation of SDL func- 
tiors in Systems Analysis' SDL model be conducted. 


PURPOSE AND SCOPE 

The purpose of this modeling analysis is to evaluate the SDL 
system design changes discussed in Reference 3. 

The scope of this analysis is limited to those system design 
changes recommended and not rejected by SDL de>/elcpers and also 
limited to the FC Mode in the ALT environment. 
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OBJECTIVES AND ACCOMPLISHMENTS 


The objective of this analysis effort was to evaluate the 
impact of the referenced SDL system design recommendations in the 
following areas; 

• Host's ability to provide real time response to Flight 
Computer (FC) commands 

« Average Host system CPU utilization 

• SDL Response Time rang'e and average. 

The above objective has been achieved by analyzing data from com- 
puter simulation runs which were based on: 

• Computer simulation model representing current SDL Host & 
FEID designs 

• Driven by ALT I/O profile generated by Systems Analysis' 
simulation model of the functional ALT Flight Software 
Design as of 2/1/75 (Appendix C) 

• SDL ALT Math Model execution sequence & measured processing 
times (math models & output calibration) supplied by SDL 
developers 4/14/75 (Appendix D) 

• SDL ALT math model estimated processing times (resulting 
from changes in model requirements) supplied by developers 
7/10/75 (Appendix E) 

• Host-Host (PDAl) traffic profile provided by SDL personnel 
(Appendix F) 

o Control program services supplied by Systems Analysis' 
simulation model of EOS 


METHOD OF ANALYSIS 

The method of this analysis was to develop a revised baseline 
model of the current SDL design with updates provide by SDL 
developers since SDL DDR 6/4/75. This was accomplished by upgrading 
Systems Analysis' SDL Model with logic & timing modifications and 
new math model processing estimates. The results of the baseline 
model was used as a basis when evaluating each of the specific 
system designs outlined in Reference 3. 



RESULTS 


A simulation ri^ of the new baseline model shows 15 out of 25 

providing real time response to FC commands. The number 
of real time minor cycles was based on PSW's 15 ms requirement for 

actually modeled. The average SDL response time 
was 24.6 ms as shown in Figure 1. 

A si^ary of system design (SD1-SD12) evaluation results obtained 
using this new baseline model appears in Table 1 along with an expla- 

modeled. Design change effects^on the LSe- 
line model results ranged from ; 

• 0,1 ms to 2.3 ms SDL response time improvements 

• -0,8 ms to +1.9 ms per minor cycle CPU processing impact 

• 0 to 10 additional real time minor cycles. 

The important point, however, is that none of the system 
designs recommended (SD1-SD12) individually achieved real time 
response to FC commands and CPU utilization under 85 percent. 

A presents individual design evaluation results in detail 
?eportld^^^^^ causes for CPU utilization and SDL response impacts 

with design change improved Host performance 

utilization and response guidelines desired, combi- 
nations of design changes (SDA-SDD) were simulated (results ore- 
sented in Table 1) . Of the combinations simulated, only oL^TsDD) 
met the performance targets established. ^ 

This system design showed 83.8 percent CPU utilization SDL 
response time of 19.5 ms and achieved real time response ?S'pf 

commands in every minor cycle. The detailed results for this case 
are presented in Appendix B. 
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FIGURE 1 

BASELINE CASE OF 

CURRENT SDL DESIGN RESPONSE TIME BREAKDOWN 

(times in milliseconds) 


TOTAL elapsed SDL RESPONSE TIME 


RANGE 

AVERAGE 


I 

I 


_ 22.3 - 26.9 ' ^ 

24.6 

HOST 

STARTUP 

TIME 

PASS 1 1 

MODEL EXECUTION 

PASS I AND 
PASS II 
OUTPUT 
CALIBRATION 

pdaI 

TRANSFER 

3.7 - 4.3 

— — V 

9.0 

3.1 - 3.3 

^ -v. 


V J 

4.0 

9.0 

3.1 

S 7 

. 7.5 


SDL RESPONSE COMPLETE TIME (FROM START OF MINOR CYCLE): 

RANGE: 38.3 - 43,6 average: 41,2 

NUMBER OF REAL TIME MINOR CYCLES* - 15 


^NUMBER OF MINOR CYCLES PROVIDING REAL TIME RESPONSE TO FC COMMANDS WITH TRANSPORT 
LAG 1 15 MS. 

^STARTS WHEN DATA COLLECTION OF EOML DATA HAS COMPLETED; AVERAGE FET=16,6MS (rANGE= 

14.5-18. 7ms) 

SO’‘RCE: SDL MODEL BASE CASE RUN 8/1/75 


TABLE 1 






SYSTEM DESIGN EVALUATION SUMMARY 




ITEM 

NO. REAL* 
TIME 

MINOR CYCLES 

AVERAGE 
PROCESSING 
PER MINOR 
CYCLE (ms) 

AVERAGE 
CPU TIME 
IMPACT PER , , 

MINOR CYCLE(MS) 

SDL 

RESPONSE, 
TIMES (ms) 

SDL 

RESPONSE 
IMPACT (ms) 

AVERAGE 
CPU % 
ADJUSTED 
FOR REAL 
TIME 

COMMENTS 


BASE CASE 

15 

32. iJ 


21}. 6 


81.0 


sdI 

OVERLAP PDAI with PASS II 
.MODEL EXECUTION 

20 

311.3 

+1.9 

23.7 

-0.9 

85.8 

INCREASE DUE TO EXTRA 
CALIBRATION AND I/O 
HANDLING (a)+ 

sd2 

CALIBRATE PASS I MATH 
MODEL OUTPUT AFTER PASS 
I MODEL EXECUTION 

22 

32.7 

+0.3 

23,5 

-1.1 

81.8 

INCREASE DUE TO EXTRA 
CALIBRATION (a) 

sd3 

TRANSFER OUTPUT (HEADER + 
DATA + filler) OF PASS I 
MODELS AFTER PASS I MODEL 
EXECUTION 

25 

31}. 3 

+1.9 

22.3 

-2.3 

85.8 

INCREASE DUE TO EXTRA 
CALIBRATION AND I/O 
HANDLING (a) 

sdA 

ACCUMULAtE 102^1 BYTES OF 
NON-PRIORITY DATA PRIOR 
TO ISSUING SVC TO RTLOG 

CURRENTLY 

IMPLEMENTED 

INTO SDL DESIGN & 

INCLUDED IN 

BASECASE 



sd5 

USE MDM PROM WORDS AS A 
DIRECT INDEX 



NOT MODELED 




PROM IMAGE MUST 
BE USED PER M. 
GAMBLE 

sd6 

INPUT/oUTPUT CALIBRATION 
& MODEL DATA BASE RE- 
VISION 

15 

32.3 

-0.1 

21}. 5 

-0.1 

80.8 

DECREASE DUE TO 2us/ 
LOGICAL DEVICE SAVINGS 
NO SAVING FOR OUTPUT 
CALIBRATION PER B. 
TAYLOR (a) 


*NUMBER OF REAL TIME MINOR CYCLES MEETING REAL TIME RESPONSE TO FC COMMANDS WITH TRANSPORT LAG 1 15 MS. 
+LETTERS IN PARENTHESES INDICATE THE APPENDIX WHICH CONTAINS DETAIL RESULTS OF SPECIFIC DESIGN. 


SYSTEM DESIGN EVALUATION SUMMARY (CONT.) 



ITEM 

NO. REAL* 
TIME 

MINOR CYCLES 

AVERAGE 
PROCESSING 
PER MINOR 
CYCLE (ms) 

AVERAGE 
CPU TIME 
IMPACT PER 
MINOR CYCLE (ms) 

SDL 

RESPONSE 

times(ms) 

SDL 

RESPONSE 
IMPACT (ms) 

AVERAGE 
CPU 1 
ADJUSTED 
FOR REAL 
TIME 

COMMENTS 

sd7 

REVISE FEID (DECREASE 

Bcw required) 



NOT MODELED 




INFEASIBLE AT PRE- 
SENT PER M. GAMBLE 

sd8 

GROUP PARAMETERS FOR 
CALIBRATION BASED ON 
FSW READ FREQUENCY 

22 

31.6 

-0.8 

22.5 

-2.1 

79.0 

DECREASE DUE TO LESS 
OUTPUT CALIBRATION 
PROCESSING (a) 

sd9 

REMOVE ERROR CHECK 
FROM FEID ACCESS 
METHOD 

15 

32.3 

-0.1 

2i|.5 

-0.1 

80.8 

DECREASE DUE TO FEID 
ERROR CHECK PROCESS- 
ING REMOVED (a) 

sdIO 

REVIEW CURRENT 
CALIBRATED OUTPUT 



NOT MODELED 




NO SIGNIFICANT IMPACT 
TO SDL^ NOT FEASI- 
BLE PER M. GAMBLE 

soil EXECUTE MODELS AT FSW 
READ FREQUENCY 



NOT MODELED 




NEED TO MEET REAL TIME 
WITHOUT- THIS DESIGN 
PER D. HORNER 

sd12 

EVALUATE CALCULATIONS 
BASED ON DEMAND 
RESPONSE INPUTS 



NOT MODELED 




DEMAND RESPONSE AC- 
TIVITY NOT MODELED 

SDA 

CHANGE IN DATA COL- 
LECTION BUFFER SIZES 

22 

32.7 

+0.3 

23.6 

-1.0 

81.8 

INCREASE DUE T0,PDA2 
I/O HANDLING (b) 

SDB 

COMBINATION OF SD1-3 
(not additive) 

25 

35.9 

+3.5 

20.1 

-ii.5 

89.8 

INCREASE DUE TO 
EXTRA CALIBRATION 
AND l/o HANDLING (B) 


SYSTEM DESIGN EVALUATION SUMMARY (CONTi) 


/■ .A 

V: > 



ITEM 

NO, REAL* 
TIME 

MINOR CYCLES 

AVERAGE 
PROCESSING 
PER MINOR 
CYCLE (ms) 

AVERAGE 
CPU TIME 
IMPACT PER 
MINOR CYCLE(ms) 

SDL 

RESPONSE 
TIMES (ms ) 

SDL 

RESPONSE 
IMPACT (ms) 

AVERAGE 

CPUZ 

ADJUSTED 
FOR REAL 
TIME 

COMMENTS 1 

SDC 

COMBINATION OF SD6j SDS^ 
SD9y SDAj SDB 

25 

34.9 

+2.5 

17.3 

“7.3 

87.3 

i 

INCREASE DUE TO EXTRA 
CALIBRATION AND I/O 
HANDLING (B) :: 

SOD 

1 

1 

COMBINATION OF SD3^ SD6. 

sd8^ sd9. sda 

25 

33.5 

+1.0 

19.5 

-5.1 

83.8 

) ] 
ij 

increase due to extra 

OUTPUT CALIBRATION H 

AND I/O HANDLING (b) 


■ <i 
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RECOMMENDATIONS AND CONCLUSIONS 


Based on analysis of simulation recjnn-c i 

elusions are made; i«^-«.arion results the following con- 

• Host response time can be improved to support real time by: 

• more overlap of CPU with PDA! I/O 

* IrSqSincy'’^""""'^""" calibration based on FSW read 

• reLT?rplesSntel arS Vo Proftf"!™ 

real ^^'JUanca that can support 

systa. assign (SDO, is J™nrio“LriSrJ;causaT^“ 

• Less impact to SDL design 

•• No break-up of Pass II models 

*• Output calibration and PDAl transfers remain the same 
operating one after the other. ' 

niarf“°aSficSt°Spu\vf?!aM?iS? f a 

• raqiir^rLr^oL^jjaJL'LSvftv^ ®“ 

yciic activity and the estimated OFT growth 

processing Sstimatel and\efsu?ed^time'^and'^^^ include 
SDL functions e c operation of 

Analysis* SDL 'model! ^ ihration routine, in Systems 






SCHEDULE 


The syst^ designs accepted by SDL 10/2/75 and to be imple- 
mented into the SDL design are: mipxe 

® SDl - Implies the following change to SDL response time 

Host startup (Input calibration + PDA2 transfer) 

Pass II model execution (WLA, ACS, AER, EOM & RGA) 
Calibration of Pass II data 
PDAl transfer of Pass II data and BCW's 
Pass III model execution (IMU) 

Calibration of Pass III data 

PDAl transfer of Pass III data and Pass I & III BCW's 

• SD2 - Calibrate Pass 1 data after Pass I model execution 

• SD8 - Calibrate model data based on FSW read frequency. 

• SDA - Data collection buffer size change; 128 bytes for 
Priority and 1024 bytes for Non Priority. 

have Ser?dentffiea- analysis the following milestones 


Milestones 


Completion Dates 


Upgicade SDL model to new design 
Analysis of FC commanding all busses 
Analysis of FC ALT new design 
Final Report 
Parameter Table Update 


10/8/75 

10/15/75 

10/17/75 

10/27/75 

10/27/75 
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APPEN:)IX a 


DETAIL RESULTS OF SYSTEM DESIGN 1 



Pass I 
HS 

Pass II 
C 

S, T 
Pass III 
C 

S, T 


Pass I model execution 
Host startup time (Input calibration + 
PDA2 transfer) 

NLA, ACS, AER, EOM, RGA model execution 
Calibrate Pass I & II model data 
Start I/O and transfer calibrated data 
IMU model execution 
Calibrate IMU model data 

Start I/O and transfer calibrated data + 
all BCW's 


14.0 


4.0 
4.6 
2.2 
3. -4 
4.4 

1.0 


4.4 


Number of adjusted real time minor cycles (MC) 

Number of real time minor cycles observed 

CPU processing per minor cycle 

CPU processing time impact 

SDL Response time 

SDL Response time impact 

Average CPU % adjusted for real time 


20 me 

11 me 

34.3 

+1.9* 

23.7 

-0.9+ 

85.8% 


*Incrcasc due to extra output calibration and I/O handling 
+Decreasc due to overlapped I/O and CPU 
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REPROLUCIBILrrY OF ™ 
ORIGINAL PAGH IS 


APPENDIX A 


DETAIL RESULTS OF SYSTEM DESIGN 2 


SGML EOML SGML 



Pass I Pass I model execution 14.0 
C Calibrate Pass I model data 1.2 
HS Host startup time (Input calibration + 

PDA2 transfer) 4.0 
Pass II Pass II model execution 9.0 
C Calibrate Pass II model data 2.0 
S, T Start I/O and transfer calibrated data + 

all BCW s 7.5 


Number of adjusted real time minor cycles (MC) 22 me 

Number of real time minor cycles observed 12 me 

CPU processing per minor cycle 32.7 

CPU processing time impact +0.3* 

SDL Response time 23.5 

SDL Response time impact - -1.1+ 

Average CPU % adjusted for real time 81.8% 


* Increase due to extra AMOD processing during output calibration 
+Decrease due to less items calibrated during SDL response time 
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DETAIL RESULTS OF SYSTEM DESIGN 3 



Pass I 
C 

S, T 

B 

HS 

Pass II 
C 

S, T 


Pass I model execution 14 n 

Calibrate Pass I model data i n 

Start I/O and transfer calibrated data 2*0 

Background processing _ 

Host startup time (Input calibration + 

PDA2 transfer) ^ 

Pass II model execution q*n 

Calibrate Pass II model data 2.0 

Start I/O and transfer calibrated data + all BCW s 6.0 


Number of adjusted real time minor cycles (MC 

Number of real time minor cycles observed 

CPU processing per minor cycle 

CPU processing time impact 

SDL Kesponsc time 

SDL Response time impact 

Average CPU % adjusted for real time 


25 me 
17 me 

34.3 
+1 . 9 * 

22 . 3 
-2.3 + 
85.8% 


* Increase due to extra output calibration 
+Decrease due to less items calibrated and 
SDL response time. 


and I/O handling, 
transferred during 
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DETAIL RESULTS OF SYSTEM DESIGN 6 


SGML 


Pass I 


Symbol Explanation 


EOML 


HS I Pass II 


SGML 



Average 
Response Time 
(in milliseconds) 


Pass I 
HS 

Pass II 
C 

S, T 


Pass I model execution 

Host startup time (Input calibration + 

PDA2 transfer) 

Pass II model execution 

Calibrate Pass I & II model data 

Start I/O and transfer calibrated data + BCW's 


14 . 0 

3.9 

9.0 

3.1 
7.5 


NumbeL of adjusted real time minor cycles (MC) 
Number of real time minor cycles observed 
CPU processing per minor cycle 
CPU processing time impact 
SDL Response time 

SDL Response time impact , 

Average CPU % adjusted for real time 


15 me 
7 me 
32.3 
-0.1* 
24.5 
— 0 . 1 + 
80.8% 


*Decrease due to the 2ti s/logical device less processing required 
during input calibration processing time. 

+Decrease results from less processing time during input calibration 
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SGML 


DETAIL RESULTS OF SYSTEM DESIGN 8 
EOML 


SGML 



Symbol Explanation 


Average 
Response Time 
(in milliseconds) 


Pass I 
HS 

Pass II 
C 

S, T 


Pass I odel execution 

Host startup time (Input calibration + 

PDA2 transfer 
Pass II model execution 

Calibrate Pass I & II model data at 12.5 hz for 
ADS, IMU, TAG, RAD and MLS at 5 hz . 

Start I/O and transfer calibrated data + BCW’s 


14.0 

4.0 

9.0 

2.1 
6.2 


Number of adjusted real time minor cycles (MC) 22 me 

Number of real time minor cycles observed 18 me 

CPU processing per m i ’’or cycle 31,6 

CPU processing time . npact -o!s* 

SDL Response time 22 5 

SDL Response time impact ^ -2.'l + 

Average CPU % adjusted for real time 79 o% 


*Decrease due to the reduction of data items output calibrated 
which varies from 43 to 141 data items. 

+Decrease results from less data items output calibrated 
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DETAIL RESULTS OF SYSTEM DESIGN 9 



Pass I 
HS 

Pass II 
C 

S, T 


Pass I model execution 

Host startup time (Input calibration + 

PDA2 transfer 
Pass II model execution 
Calibrate Pass I & II model data 
Start I/O and transfer calibrated data + BCW 


14.0 

4.0 

9.0 

3.1 
7.5 


Number of adjusted real time minor cycles (MC) 15 me 

Number of real time minor cycles observed 7 me 

CPU processincj per minor cycle 32.3 

CPU processing time impact -0.1* 

SDL Response time 24.5 

SDL Response time impact .. -0.1+ 

Average CPU % adjusted for real time 80.8% 


*Decrease due to not executing FEID Access Method error check. 
tDecrease results from less processing during PDAl transfers. 
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EEPRODUCIBILnY OF THE 
ORIGINAL PAGE IS POOR 




SGML 


DETAIL RESULTS OF SYSTEM DESIGN A (buffer sizes) 

COMT 

SGML 



Symbol 


Pass I 
HS 

Pass II 
C 


Explanation 


Average 
Response Time 
(in milliseconds) 


Pass I model execution 

Host startup time (Input calibration + 

PDA2 transfer) 

Pass II model execution 

Calibration Pass I & II model data 

Start I/O and transfer calibration data + BCW 


14.0 


2 

9, 

3, 


7,5 


Number of adjusted real time minor cycles (MC) 

Number of real time minor cycles observed 

CPU processing per minor cycle 

CPU [processing Lime impact 

SDi. Response Lime 

SDI, Response time impact 

Avei cuji': CPU Z adjusted for real time 


22 me 
10 me 
32.7 
+ 0.3* 
23.6 
-1 . 0 + 
81,8% 


* during PDA2 data collection buffers. 

(Two 64 halfword buffers filled per minor cycle in this design 
instead of one 256 halfword buffer during base case). Overlapping 
savings resulting from less SVC • s to RTLOG. J-apping 

+Decrease results from overlapping PDA2 I/O 'with input calibration 

transfer time because first trLsfer is competed 
i0% of the time before EOML is data collected. ^mpierea 
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APPENxIX B 


DETAIL RESULTS OF SYSTEM DESIGN B(SDl-3) 


SGML EOML SOML 



Response Time 
(in milliseconds) 


Pass 

I 

Pass I model execution 


14.0 

C 


Calibrate Pass I model data 


1.2 

S, T 


Start I/O and transfer calibrated data 


2.0 

B 


Background processing 


NA 

HS 


Host startup time (Input calibration + 


4.0 



PDA2 transfer) 


Pass 

II 

NLA, ACS, AER, EOM, RGA model execution 


4.6 

C 


Calibrate Pass II model data 


1.0 

S, T 


Start I/O and transfer calibrated data + 

BCW's 




for Pass II models 


4.4 

Pass 

III 

IMU model execution 


4.4 

C 


Calibrate IMU model data 


1.0 

S, T 


Start I/O and transfer calibrated data + 

rest 




of BCW's 


O 

* 


Number of adjusted real time minor cycles (MC) 

Number of real time minor cycles observed 

CPU processiny per minor cycle 

CPU processing time impact 

SDL Response time 

SDL Response time impact 

Average CPU % adjusted for real time 


NA 

2 5 r.ic 
35.9 
+ 3.5* 
20.1 
-4.5 + 
89.8% 


* Increase due to two extra output calibration and I/O handling 
+Decrease due to less data calibrated and transferred during SDL 
response time and overlapped I/O and CPU. 
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DETAIL INSULTS OF SYSTEM DESIGN C(SD6, 8, 9, A, B) 


SGML 


EOML 




Pass I j C S 

i/ 

HS 1 Pass IljC 1 S 

Pass III|C |S 



1 

T 

T 

T 


Symbol Explanation 


Pass 

C 

S, 

B 

HS 


T 


Pass 

C 

S, T 

Pass 

C 

S, T 


I Pass I model execution 
Calibrate Pass I model data 

Start I/O and transfer calibrated data 

Background processing 

Host startup (Input calibration + 

PDA2 transfer) 

II NLA, ACS, AER, EOM, RGA model execution 
Calibrate Pass II model data 

Start I/O and transfer calibrated data + 
Pass II BCW;s 

III IMU model execution 
Calibrate Pass III model data 

Start I/O and transfer calibrated data + 
of BCW's 


Average 
Response Time 
(in milliseconds) 
14.0 
0.6 
1.1 
NA 


2 , 

4 , 


rest 


1.0 

4.4 

4.4 

0.5 

1.0 


Number of adjusted real time minor cycles (MC) 

Number of real time minor cycles observed 

CF’U process imr per minor cycle 

CPU processing time impact 

SOL Response t: ime 

SDI. Response time impact 

Average CPU 't> adjusted for real time 


NA 

25 me 
34.9 
+ 2.5* 
17.3 
-7,3 + 
87.3% 


* Increase due to extra output calibration, I/O handling and SDA 
overlapping saving resulting from SD6, 8 and 9 
+Decrease results from SD6, 8, 9, A & B. 


1 
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APPENOIX B 


DETAIL RESULTS OF SYSTEM DESIGN D(SD3, 6, 8, 9, A) 


SOME EOML some 



Pass I 
C 


S, T 


B 

HS 

Pass 

C 


S, T 


II 


Pass I model execution 14.0 

Calibrate Pass I model data at 12.5 hz for IMU, 

TAC , ADS and RAD and 5 hz for MLS 0 . 6 

Start I/O and transfer calibrated data 1.1 

Background processing 

Host startup time (Input calibration+PDA2 transfer) 2.8 

Pass II model execution 9.0 

Calibrate Pass II model data 12.5 hz for IMU 1.5 

Start I/O and transfer calibrated data + all 
BCW 5 . 2 



^:^ILITY 0? THE 
12 POOR 


Number of adjusted real time minor cycles (MC) 


Number of real time minor cycles observed 23 me 

CPU processing per minor cycle 33.5 

CPU processing time impact +1.0* 

SDL Response time ’ 19.5 

SDL Response time impact ^ -5.1+ 

Average CPU % adjusted for real time 83.8 


* Increase due to extra calibration and I/O handling overlapping 
savings resulting from SD6 , 9 and 8 
i-Decrease results from SD3, 6, 8, 9, A 
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Aopfjndix C 


I/O Definitions For GNC Mated Flight, Sep., TAEM, A/l Major Modes 


WORDS/ 

MDM 

INPUT GROUP 1 

Accel Assembly 2 

RH RHC 3 

RH RPTA 1 

RH SBTC 1 

LH RHC 3 

LH RPTA 1 

LH SBTC 1 

FFl Discretes 7 

FF2 D iscretes 6 

FF3 Discretes 7 

FF4 Discretes 5 

I 

'^ '°UT GROUP 2 

* Rate Gyro Assembly 3 

Actuator Feedback 7 

FAl Discretes 2 

FA2 Discretes 2 

FAS Discretes 2 

FA4 Discretes ] 

Aft Attach Pt. Volt. 2 

APU Pressures 1 

INPUT GROUP 3 

Fwd. Attach Pt. Volt. 1 

ADTA 7 

IMU 14 

MSBLS 3 

TAChN 4 

TACAN Control Reg. 2 

Radar Altimeter 1 

fTime Tag) 


TOTAL 

WORDS 

RATE 

MDM’s 

BCE's 

6 

25 

FFl-3 

10-12 

9 

25 

FFl-3 

10-12 

3 

25 

FFl -3 

10-12 

3 

25 

FFl-3 

10-12 

9 ‘ 

25 

FFl-3 

. 10-12 

3 

25 

FFl-3 

10-12 

3 

25 

FFl-3 

10-12 

7 

25 

FFl 

10 

6 

25 

FF2 

11 

7 

25 

FF3 

12 

5 

25 

FF4 

13 


9 

25 

FAl-3 

14-16 

28 

25 

FA 1-4 

14-17 

2 

25 

FAl 

14 

2 

25 

FA2 

15 

2 

25 

FA3 

16 

1 

25 

FA4 

17 

4 

25 

FA1,FA2 

14, 15 

3 

25 

FA 1-3 

14-16 


2 

12.5 

FFl ,FF2 

10,11 

28 

12.5 

FFl -4 

10-13 

42 

12.5 

FFl-3 

10-12 

9 

12.5 

FFl-3 

10-12 

12 

12.5 

FFl-3 

10-12 

6 

12.5 

FFl-3 

10-12 

2 

12.5 

FF1,FF2 

10,11 


Source: ALT FSW Preliminary Design Review 3/10/75 
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Appendix C 


I/O Definition For GNC (Cont'd.) 


WORDS/ 

MDM 

OUTPUT GROUP 1 

ASA Commands 6 

F A1 Discretes 4 

FA2 Discretes 4 

FA3 Discretes 4 

FA4 Discretes 2 

OUTPUT GROUP 2 

FFl Discretes 8 

FF2 Discretes 8 

FF3 Discretes 8 

FF4 Discretes 4 

SPI 1 

TACAN Control Reg. 2 

IMU Torque & Slew 2 


OUTPUT GROUP 3 

Dedicated Disploy ^1 
Dedicated Display ^2 


TOTAL 

WORD 

RATE 

MDM's 

BCE’s 

24 

25 

FA 1-4 

14-17 

4 

25 

FAl 

14 

4 

25 

FA2 

15 

4 

25 

FA3 

16 

2 

25 

FA4 

17 


8 

12.5 

FFl 

10 

8 

12.5 

FF2 

n 

8 

12.5 

FF3 

12 

4 

12.5 

FF4 

13 

1 

12.5 

FFl 

10 

6 

12.5 

FFl-3 

10-12 

6 

12.5 

FFl-3 

10-12 


37 

37 


ni 

in 


12.5 

12.5 


DDU 1 
DDU 2 


10,11,13 

10-12 


A/L I/O Definitions For SM And Ul 



Read/ 

Words/ 

Total 

Rate 

Exec 

Device BCE 


Write 

Device 

Words 


Cycles 

downlist processor 







Downlist Buffer 

W 

128 

128 

25 

1-25 

DACBU 24 

deu polling 







DEUl Poll 
DEU2 Poll 
DEU3 Poll 

R 

R 

R 

1 

1 

1 

1 

1 

1 

5 

5 

5 

1-5 

1-5 

1-5 

DEUl 6 
DEU2 7 
DEU3 8 

SM DATA ACQUISITION 







Obtain Data 
Obtain Status Byte 

R 

R 

37 

1 

37 

1 

7 

1 

1-10 

5 

DACBU 1 24 
DACBU 1 24 

DISPLAY UPDATE 







Final Approach Display 

W 

25 

25 

10 

1-10 

DEUl A 

System Summary Display 

W 

282 

282 

1 

2 

V U IJ f \J 

DEU 2 7 
DEU3 8 

RM-CONT Display 

w 

347 

347 

1 

3 


APPENDIX D 


ALT HOST MATH MODEL CHARACTERISTICS 


MODEL 


SMDLGSEN 

SMDLXDDM 

SMDLGLDS 

SMDLENVl 


IbMDLGNAV 


SMDLSPMU 

SMDLRCLK 


I MU (2) 

RGA 

NLA 


eomQ) 

ERVl 

ATM 

WND 

GRA 

aerQ) 



ALL 

EVEN 


TAC 

6LL ,, 

2.160 

MLS 

3 , 8 . 13 , 

l 8 , 13 . 

.900 

RAD 

ALL 

,600 

IMlXl) 

ALL 

.950 

ADS 

ALL 


PMU 

ALL 

- 

1 ALL 




.550 

1.830 

.620 

2.QQ0 

3:830 

8,800 

2 - 25 th mc 


SOURCE ; SDL DEVELOPMENT PERSONNEL^ 4 / 14/75 


REPRODUCIBILITY OP THE 

OIIIOEnAL PAOP is poor 
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O' 


ALT HOST MATH MODEL CHARACTERISTICS 


MODULE 

NAME 

MODEL 

NAME 

SMDLGACS 

ACS 

SMDLENV2 

aer(2) 

eom(2) 

SMDLGSEN 

imu(2) 

RGA 

NLA 

SMDLXDDM 

DDM 

DDS 

SMDLGLDS 

LDS 

SMDLENVl 

eom(1) 

ERVl 

AFP 

PER 

ATM 

GRA 

LND 

aerI 

SMDLGNAV 

TAC 

MLS 

IMU(l) 

ADS 

SMDLSPMU 

PMU 

SMDLRCLK 

- 


JV^^E NO. 

ALL 

ALL 

ALL 

ALL 

ALL 

ALL 

ALL 

EVEN 

ALL 

ALL 

ALL 


n.M043,16,19,22.25 

mimm 

ALL 

ALL 


!'rk.l3,18.23 

ALL 

ALL 

ALL 

ALL 

ALL 


ESTIMATED, ^ 
CPU/EXEC (ms) 

1.881 

1.260 

.890 

.^120 

.250 

.600 



3.i 

8.600, 320+ 



.500 


+FIRST TIME REPRESENTS MODEL EXEC TIME FOR IST MINOR CYCLE 
SECOND TIME REPRESENTS MODEL EXEC TIME FOR 2nD"25tH MINOR CYCLES 

SOURCES: SDL PERSONNEL 7/10/75 
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APPENDIX F 


ALT HOST-TO-FEID PDaI TRAFFIC PROFILE MODELED 


NUMBER OF WORDS 


CALIB 


OTAL OU 


CYCLES OUTPUT 


SMDLGACS/ 

ACS FDBK. SIG. 
ACS DISC, SIG. 

smdlenv2/- 

smdlgsen/ 

imu(2) 

RGA 

NLA 

RGA DISC. 


NONE 


NONE 


smdlglds/lds 

SMDLENVl/- 

smdlgnav/ 


NONE 

NONE 


NONE 

NONE 


ALL 

3.8.13.18.23 

ALL 

ALL 


nav disc, 


included with 
CSB discretes 


CSB DISC. 
MAN CONTROL 


DEMAND RESPONSt 
DEMAND RESPONSE 


DEMAND RESPONSE 


SMD LSPMU/PMU I 0 I 

SOURCE: SDL PERSONNEL 3/75 

'includes fill. HEADER. & FEID BUFFER CONTROL WORDS 









